Item Reviewed
| Token Server Client & Java BrowserID crypto library for Android services projects | |||||||||||||||||||||||||||||||||||||||||||||
| Target | Key server protocol describing client-side key stretching and how to talk to the Fx Account server:
https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol
2 Total; 1 Open (50%); 0 Resolved (0%); 1 Verified (50%); HTTP Client for interacting with FxAccount server: (getting a signed Browser ID certificate)
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); Code for generating HAWK Authorization: headers
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); Code that actually authenticates to new Sync storage endpoints with tokens
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%); This ticket will cover exposing a username/password sign up/sign in flow of some sort.
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%); |
||||||||||||||||||||||||||||||||||||||||||||
{{#set:SecReview name=Token Server Client & Java BrowserID crypto library for Android services projects |SecReview target=Key server protocol describing client-side key stretching and how to talk to the Fx Account server: https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol
| ID | Summary | Priority | Status |
|---|---|---|---|
| 935671 | Security Review - TokenServerClient | -- | NEW |
| 935707 | SecReview: Java BrowserID crypto library for Android services projects | -- | VERIFIED |
2 Total; 1 Open (50%); 0 Resolved (0%); 1 Verified (50%);
HTTP Client for interacting with FxAccount server: (getting a signed Browser ID certificate)
| ID | Summary | Priority | Status |
|---|---|---|---|
| 892025 | Implement Android client for PICL Authentication/Keyserver | -- | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
Code for generating HAWK Authorization: headers
| ID | Summary | Priority | Status |
|---|---|---|---|
| 903123 | Implement Hawk authentication header provider for Android Background Services | -- | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
Code that actually authenticates to new Sync storage endpoints with tokens
| ID | Summary | Priority | Status |
|---|---|---|---|
| 918012 | Make Android Sync authenticate against Sync 1.1 with token server tokens | -- | VERIFIED |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);
This ticket will cover exposing a username/password sign up/sign in flow of some sort.
| ID | Summary | Priority | Status |
|---|---|---|---|
| 899217 | First version of Firefox Account sign up/sign in screen on Android | -- | VERIFIED |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
These tickets are all part of gluing the Fx Accounts sign up/log in flow on top of Android Sync. The use case is that a user wants to create a new account, or sign in to an existing account with an email address and password. Once we have things derived from the email/password pair, we need to shuffle various access tokens around. These tickets do that shuffling.
What solutions/approaches were considered other than the proposed solution?
I guess we investigated about a billion different variations on email/password, including Sync-style pairing and lots of client-side key stretching schemes. We settled on a PBKDF2 + Scrypt + PBKDF2 sandwich. Brian Warner (warner) is a better reference for what was considered. But these tickets don't dig into the meat of the client-side key stretching; they assume you get the tokens from somewhere and shuffle.
Why was this solution chosen?
This is almost exactly the token server dance that was intended for Sync 2.0 before Fx Accounts was a thing. There's just not many ways to dance this dance. I suppose you could ask why a Browser ID assertion instead of, say, just HAWK credentials. It decouples the auth server and the storage servers by introducing a token server in the middle. This should help third parties stand up Fx Account-authenticated endpoints. I'll further interpret this to mean, technically, "Why are we doing this in Java?" We do this in Java because Gecko is not running when we Sync. End of story. Loading Gecko to do this work is not feasible.
Any security threats already considered in the design and why?
Lots. The whole token server dance and cryptography has been analyzed, mostly by ckarlof and warner, on a whole range of facets. I'd like to focus this on the actual implementation of the dance to make sure I haven't done something foolish. We have considered the Android SecureRandom random issue https://bugzilla.mozilla.org/show_bug.cgi?id=903907 but don't think it will affect us. (My memory here is hazy.)
Threat Brainstorming
' {{#set: SecReview feature goal=These tickets are all part of gluing the Fx Accounts sign up/log in flow on top of Android Sync. The use case is that a user wants to create a new account, or sign in to an existing account with an email address and password. Once we have things derived from the email/password pair, we need to shuffle various access tokens around. These tickets do that shuffling. |SecReview alt solutions=I guess we investigated about a billion different variations on email/password, including Sync-style pairing and lots of client-side key stretching schemes. We settled on a PBKDF2 + Scrypt + PBKDF2 sandwich. Brian Warner (warner) is a better reference for what was considered. But these tickets don't dig into the meat of the client-side key stretching; they assume you get the tokens from somewhere and shuffle. |SecReview solution chosen=This is almost exactly the token server dance that was intended for Sync 2.0 before Fx Accounts was a thing. There's just not many ways to dance this dance. I suppose you could ask why a Browser ID assertion instead of, say, just HAWK credentials. It decouples the auth server and the storage servers by introducing a token server in the middle. This should help third parties stand up Fx Account-authenticated endpoints. I'll further interpret this to mean, technically, "Why are we doing this in Java?" We do this in Java because Gecko is not running when we Sync. End of story. Loading Gecko to do this work is not feasible. |SecReview threats considered=Lots. The whole token server dance and cryptography has been analyzed, mostly by ckarlof and warner, on a whole range of facets. I'd like to focus this on the actual implementation of the dance to make sure I haven't done something foolish. We have considered the Android SecureRandom random issue https://bugzilla.mozilla.org/show_bug.cgi?id=903907 but don't think it will affect us. (My memory here is hazy.) |SecReview threat brainstorming=' }}
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
| nalexander :: try to find diagram showing token flows through servers and clients for dchan :: Friday, 22 November
dchan :: reach out to platform / fxos teams for their implementations of this dance :: Friday, 22 November yvan :: schedule Fx Accounts sec-review for protocol :: Friday 22, November |
|
{{#set:|SecReview action item status=In Progress
|Feature version=` |SecReview action items=nalexander :: try to find diagram showing token flows through servers and clients for dchan :: Friday, 22 November dchan :: reach out to platform / fxos teams for their implementations of this dance :: Friday, 22 November yvan :: schedule Fx Accounts sec-review for protocol :: Friday 22, November }}