Security/Reviews/token crypto Android

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%);

• 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.