canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/token crypto Android: Difference between revisions
Security/Reviews/token crypto Android (view source)
Revision as of 18:47, 25 November 2013
, 25 November 2013no edit summary
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
<bugzilla> | <bugzilla> | ||
{ | { | ||
" | "id":"935671,935707" | ||
} | } | ||
</bugzilla> | </bugzilla> | ||
| Line 11: | Line 11: | ||
<bugzilla> | <bugzilla> | ||
{ | { | ||
" | "id":"892025" | ||
} | } | ||
</bugzilla> | </bugzilla> | ||
| Line 17: | Line 17: | ||
<bugzilla> | <bugzilla> | ||
{ | { | ||
" | "id":"903123" | ||
} | } | ||
</bugzilla> | </bugzilla> | ||
| Line 23: | Line 23: | ||
<bugzilla> | <bugzilla> | ||
{ | { | ||
" | "id":"918012" | ||
} | } | ||
</bugzilla> | </bugzilla> | ||
| Line 29: | Line 29: | ||
<bugzilla> | <bugzilla> | ||
{ | { | ||
" | "id":"899217" | ||
} | } | ||
</bugzilla> | </bugzilla> | ||
| Line 35: | Line 35: | ||
{{SecReview | {{SecReview | ||
|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 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. | |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. | 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. | |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. | 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. | ||