Security/Reviews/BrowserIDSync

• Property "SecReview feature goal" (as page type) with input value "* Rewrite Mozilla Sync authentication to user BrowserID (Persona) instead of basic authentication. This will go through the token server (separate security review will be conducted).
  • BrowserID Key Wrapping will be used to store a wrapped version of the user's SyncKey on the Sync Servers.
  • The decryption key will be stored (encrypted) on the BrowserID servers.

  BIDSync wiki - https://wiki.mozilla.org/Identity/BrowserIDSync
  Services documentation - http://docs.services.mozilla.com/index.html
  Tokenserver documentaton - http://docs.services.mozilla.com/token/index.html
  Current Sync server crypto model - http://docs.services.mozilla.com/sync/storageformat5.html#cryptography
  Proposed future server crypto model - http://docs.services.mozilla.com/sync/storageformat6.html (will be future security review)
  

  • [dchan] - Will users have a choice to continue with basic auth for a short while or will they have to migrate to Persona immediately?
  • [gps] We plan to have a flag day. The change is also coinciding with a new version of the Sync server stack and new Sync global storage format. We don't wish to support old and new clients on the same hardware. We theoretically could support basic auth. However, Persona accounts won't have passwords, so that makes dual support difficult. It is easier to make the clean break.

  Terminology

  Persona - browserid
  IdP - Identity Provider, browserid is one such provider, but other organizations can setup their own IdPs
  Password Key (PWK) - encryption key dervied from user's Persona password using PBKDF2
  User Key (UK) - encryption + HMAC keys generated per-email. Stored on Persona server encrypted by PWK
  Sync  Key (SK) - Sync encryption key, though Persona can take any arbitrary  blob to encrypt with UK. Currently 128 bits + HKDF derived pair of 256  bit keys. Will change to a pair of 256 bit keys.
  

  IMPORTANT, READ BELOW LINK Draft dev-planning posts on subject - https://etherpad.mozilla.org/Oe4H1LnnJm

  Overall goal is better usability of Sync. Product and UX feels current setup and pairing flow is too complicated. Upcoming "log in to the browser" feature allows Sync to piggyback off that.

  • BIDSync is an alternative authentication mechanism for Sync
    • current service uses Basic Auth
  • Since BID is not an authorization service, TokenServer will be used for authz
    • BID assertion is exchanged for an authorization token and node assignment
    • http://docs.services.mozilla.com/token/index.html
  • This also simplifies the key escrow process
    • User doesn't need both devices on hand to setup a new Sync account
    • There are concerns that the JPAKE UX is preventing multiclient adoption of Sync
  • We can potentially allow partial key recovery
    • Non-sensitive collections only
    • multiple encryption keys
    • the current sync architecture already allows for multiple collection keys" 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 "* JPAKE for key escrow
  • Basic Auth for authn / authz" 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 "* UX is better than JPAKE
  • promotes Identity" 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 "* Persona key wrapping effectively reduces Sync's security model from 128 bit Sync Key to PBKDF2 (or whatever is chosen) on Persona password.
    • Sync servers still don't have access to the user's SyncKey. Sync servers will have a blob that is wrapped by the Persona User Key (per-email key)
    • [gps] Right. But the overall chain is weakened. Sync server in isolation is still secure.
    • Sync clients could still support other forms of root key storage and transport, but derivation from Persona password being pushed to be the default. There might be staffing and support cost considerations for supporting other "official" root key management mechanisms." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "* https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
  • Persona server compromise
    • Could a compromised Persona server result in access to Sync server (via "forged" BID assertion and subsequent token)?
    • Are user keys stored in a way such that if the encrypted UKs are leaked that it would still be computationally intensive to break (assuming weak passphrase)?
      • some mechanism similar to bcrypt
      • [warner] yes, that's part of the BID-key-wrapping design. It's nowhere near as strong as the current Sync model, though.
  • How does sync deal with invalidating a user's session?
    • [dchan] I don't think this is currently possible with basic auth, but with the move to Persona, can we invalidate bid-assertions or does the secrets file on tokenserver need to be wiped for the associated node
  • Man-in-the-middle between IdP and Sync
    • How does the IdP and Sync servers perform authentication/idenity checks?
      • Does this rely purely on SSL?
        • [warner] in general, yes. The Sync server (as the RP) relies on SSL to fetch each IdP's public key, which is then used to verify assertions coming from the browser. Specific high-value domains could be pinned to specific keys, though.
      • Similar to above threat with the forged BID assertion / token
    • Is it possible for an attacker to intercept the unencrypted UK?
      • [gps] I'm pretty sure the Persona User Key is encrypted/decrypted locally. Or are you referring to the Persona credentials?
      • [dchan] Yes the User Key, looks like a non-issue then
  • Legal ramifications of storing SyncKey
    • this is slightly different from current JPAKE in that JPAKE escrow only stores the keys for a short time and in memory iirc.
      • [warner] to be clear, JPAKE is much stronger than that: the server never sees the key, even briefly. It facilitates the transfer (and can behave like a MitM or an eavesdropper), but the protocol prevents such attackers from learning anything about the transferred key. The server's behavior doesn't matter: all that matters is the math and the client-side code.
    • Are we concerned that we may be compelled to turn over a UK encrypted by a "weak" PWK, leading to compromise of SK
      • requires subpoena of both Persona and Sync products. Although Mozilla controls both at this time, there may be 3rd party IdP in the future.
        • [warner] once the weakly-encrypted UK is turned over, and brute-force used to deduce the password and PWK, then the attacker can fetch the Sync data just like the normal client. One one compromise/subpoena (of the Persona data, on the IdP) is necessary.
  • What stops the Persona server from running PBKDF2 on the password when submitted to the server to obtain PWK and decrypt UK?
    • The wrapped SyncKey is stored on the Sync servers, so it seems like we are trusting ourselves to never abuse the currenct architecture
    • Open issue to move to SRP so password is never sent to the server
      • https://groups.google.com/forum/#!topic/mozilla.dev.identity/aACZwefnUK0
      • https://github.com/mozilla/browserid/issues/1014" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Who bug Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss

secteam bug 743809 review bwarner scrypt proposal by 1-May-2012 [NEW] new

secteam bug 743811 talk to product / jay with sync change concerns by 23-Apr-2012 [NEW] new

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);