Item Reviewed
| Browser ID Sync Integration | |
| Target | https://wiki.mozilla.org/Identity/BrowserIDSync |
{{#set:SecReview name=Browser ID Sync Integration |SecReview target=https://wiki.mozilla.org/Identity/BrowserIDSync }}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- 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
What solutions/approaches were considered other than the proposed solution?
- JPAKE for key escrow
- Basic Auth for authn / authz
Why was this solution chosen?
- UX is better than JPAKE
- promotes Identity
Any security threats already considered in the design and why?
- 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.
Threat Brainstorming
' {{#set: SecReview feature goal=* 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
|SecReview alt solutions=* JPAKE for key escrow
- Basic Auth for authn / authz
|SecReview solution chosen=* UX is better than JPAKE
- promotes Identity
|SecReview threats considered=* 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.
|SecReview threat brainstorming=' }}
Action Items
| Action Item Status | None |
| Release Target | ` |
| Action Items | |
| ' | |
{{#set:|SecReview action item status=None
|Feature version=` |SecReview action items=` }}