Security/Reviews/token crypto Android
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%); |
||||||||||||||||||||||||||||||||||||||||||||
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%);
" contains strip markers and therefore it cannot be parsed sufficiently.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
'
- Property "SecReview feature goal" (as page type) with input value "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." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview alt solutions" (as page type) with input value "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." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview solution chosen" (as page type) with input value "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." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview threats considered" (as page type) with input value "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.)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
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 |
|
