Security/Reviews/Accounts Sync
Jump to navigation
Jump to search
Please use "Edit with form" above to edit this page.
Item Reviewed
| Firefox Accounts + sync | |
| Target | Firefox Accounts
wiki: https://wiki.mozilla.org/Identity/FirefoxAccounts protocol diagrams: https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol
|
{{#set:SecReview name=Firefox Accounts + sync |SecReview target=Firefox Accounts wiki: https://wiki.mozilla.org/Identity/FirefoxAccounts protocol diagrams: https://wiki.mozilla.org/Identity/AttachedServices/KeyServerProtocol
- Firefox Accounts is consumer SSO account system which provides access to services run by Mozilla, such as Firefox Marketplace and the next version of Firefox Sync. A user can sign in with a Firefox Account to all her "Foxes": Firefox on Desktop, Firefox for Android, and Firefox OS. Signing into a Firefox browser or device gives the user access to integrated Mozilla Services on that browser or device that requires authentication (e.g., Firefox Sync). Longer term we envision that non-Mozilla services and applications will be able to delegate authentication to Firefox Accounts.
- Firefox Accounts from a high level perspective is not much to look at. It's a thin service that does only a few things, e.g.,
- It allows users to create a Firefox Account.
- It allows existing account holders to authenticate themselves, and perform related operations (reset password, change password, etc.)
- It provides a delegated authentication API to relying Mozilla services (possibly third services in the future). Just like how Google Drive delegates authentication to Google Accounts, Firefox Marketplace will delegate authentication to Firefox Accounts.
- Firefox Accounts itself doesn't store much about users, and we intend to keep it that way:
- Email address
- Password verifier
- User id
- Sync encryption keys
- Whether the user has accepted the ToS and PP
- A log of security events about the user (from where and when logins, passwords resets, etc. happen), and from what devices the user is currently logged in.
- Firefox Accounts on it's own is not terribly interesting. Firefox Accounts is only interesting and valuable when you start attaching services to it, like Firefox Marketplace, Where's My Fox, and Firefox Sync. These services will manage their own data, but rely on Firefox Accounts for single sign-on and related authentication services.
}}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- Our goal is provide a single centralized account system for current and future Mozilla Cloud Services. In the future, we might also provide delegated authentication for 3rd party apps and services.
- Mozilla needs a single account database to deliver a fantastic, integrated experience across all its products. For example, if we implement a profile service that allows users to choose an avatar, this avatar can be made available across all Mozilla Cloud Services while she is logged in to her Firefox Account.
- Unfortunately, delivering awesome services also involves some less exciting, but still important aspects, like making sure users have had a chance to inspect our terms of service and privacy policies. We must also comply with local laws and regulations, e.g., COPPA. It would be inconvenient for users to have to verify a terms of service, a privacy policy, and COPPA at each individual Mozilla service. We believe that users should only have to inspect our terms of service, privacy policy, and go through COPPA verification once for all our services. Firefox Accounts enables us to do that.
- In addition, FxA provides secure storage of the root encryption keys used to protect Firefox Sync data. We've defined two classes of data protection. "Class A" contains data which can be recovered by a traditional email-challenge or other mechanism that the server decides: the root class-A key ("kA") is known to the server. "Class B" contains data which requires knowledge of the user's password to recover: kB is encrypted by something derived from the user's password, and is *not* known by the server (although it may get a dictionary attack). To protect kB, the login protocol does not reveal the user's password to the server.
- More info here, though it duplicates a lot of what was said above
- Initial design was to redo the Sync experience, only change useragent signin for Sync
What solutions/approaches were considered other than the proposed solution?
- Persona - Persona wasn’t designed for long lived assertions or a background authentication flow. Although the current FxA auth server uses the underlying browserid technology, it isn’t Persona
Persona never had access to user password since they ID with their idp and not out system. PW is needed so that we can derive the keys
- PiCL (https://wiki.mozilla.org/Identity/PiCL) - Original name and scope of the project. Product requirements resulted in integration with FxA
- KeyWrapping (https://wiki.mozilla.org/BrowserID_Key_Wrapping) - This was one of the original designs for improving the Sync sign-up experience. The goal was to allow a user to retrieve their sync material with a username / password. Certain properties from this design were carried over such as multiple data classes with different encryption keys.
- TokenServer (https://wiki.mozilla.org/CloudServices/Sagrada/TokenServer) - This was a service designed to improve the scalability of Sync. The original design called Sync clients to contact a central login server over Basic Auth. The client would then be redirected to storage servers which used Basic Auth to protect encrypted blobs. TokenServer was designed to help with scalability issues in the initial Sync design.
- J-PAKE (https://wiki.mozilla.org/Services/KeyExchange) - This was one of the first services used for key escrow in Sync. It required a 12 character base32 PIN be shared between the initial device and subsequent device. Research showed that a majority of Sync users didn’t have multiple devices
Why was this solution chosen?
`
Any security threats already considered in the design and why?
- Bad server / actor - The KeyServerProtocol is designed to work in the presence of a compromised server except for in some initial setup. See https://blog.mozilla.org/warner/2013/07/23/picl-crypto-review/ . An attacker could attack the recoverable data, but not the non-recoverable data even if they are listening to post account setup traffic. This is because the protocol uses zero knowledge proofs for authentication. Relevant password information isn’t sent to the server outside of the proposed raw_password API.
- Data recoverablilty - There exists 2 classes of data; recoverable, non-recoverable. Mozilla will never be able to decrypt your non-recoverable data without your password (derived encryption key). Recoverable data uses a “shared” key that can be decrypted after going through an identity confirmation step e.g. e-mail verification.
- Bruteforce attack - The protocol allows for user defined number of iterations / rounds for the keystretching / derivation. However this is still orders of magnitude slower than hashing the password once.
Threat Brainstorming
' {{#set: SecReview feature goal=* Our goal is provide a single centralized account system for current and future Mozilla Cloud Services. In the future, we might also provide delegated authentication for 3rd party apps and services.
- Mozilla needs a single account database to deliver a fantastic, integrated experience across all its products. For example, if we implement a profile service that allows users to choose an avatar, this avatar can be made available across all Mozilla Cloud Services while she is logged in to her Firefox Account.
- Unfortunately, delivering awesome services also involves some less exciting, but still important aspects, like making sure users have had a chance to inspect our terms of service and privacy policies. We must also comply with local laws and regulations, e.g., COPPA. It would be inconvenient for users to have to verify a terms of service, a privacy policy, and COPPA at each individual Mozilla service. We believe that users should only have to inspect our terms of service, privacy policy, and go through COPPA verification once for all our services. Firefox Accounts enables us to do that.
- In addition, FxA provides secure storage of the root encryption keys used to protect Firefox Sync data. We've defined two classes of data protection. "Class A" contains data which can be recovered by a traditional email-challenge or other mechanism that the server decides: the root class-A key ("kA") is known to the server. "Class B" contains data which requires knowledge of the user's password to recover: kB is encrypted by something derived from the user's password, and is *not* known by the server (although it may get a dictionary attack). To protect kB, the login protocol does not reveal the user's password to the server.
- More info here, though it duplicates a lot of what was said above
- Initial design was to redo the Sync experience, only change useragent signin for Sync
|SecReview alt solutions=* Persona - Persona wasn’t designed for long lived assertions or a background authentication flow. Although the current FxA auth server uses the underlying browserid technology, it isn’t Persona
Persona never had access to user password since they ID with their idp and not out system. PW is needed so that we can derive the keys
- PiCL (https://wiki.mozilla.org/Identity/PiCL) - Original name and scope of the project. Product requirements resulted in integration with FxA
- KeyWrapping (https://wiki.mozilla.org/BrowserID_Key_Wrapping) - This was one of the original designs for improving the Sync sign-up experience. The goal was to allow a user to retrieve their sync material with a username / password. Certain properties from this design were carried over such as multiple data classes with different encryption keys.
- TokenServer (https://wiki.mozilla.org/CloudServices/Sagrada/TokenServer) - This was a service designed to improve the scalability of Sync. The original design called Sync clients to contact a central login server over Basic Auth. The client would then be redirected to storage servers which used Basic Auth to protect encrypted blobs. TokenServer was designed to help with scalability issues in the initial Sync design.
- J-PAKE (https://wiki.mozilla.org/Services/KeyExchange) - This was one of the first services used for key escrow in Sync. It required a 12 character base32 PIN be shared between the initial device and subsequent device. Research showed that a majority of Sync users didn’t have multiple devices
|SecReview solution chosen=' |SecReview threats considered=* Bad server / actor - The KeyServerProtocol is designed to work in the presence of a compromised server except for in some initial setup. See https://blog.mozilla.org/warner/2013/07/23/picl-crypto-review/ . An attacker could attack the recoverable data, but not the non-recoverable data even if they are listening to post account setup traffic. This is because the protocol uses zero knowledge proofs for authentication. Relevant password information isn’t sent to the server outside of the proposed raw_password API.
- Data recoverablilty - There exists 2 classes of data; recoverable, non-recoverable. Mozilla will never be able to decrypt your non-recoverable data without your password (derived encryption key). Recoverable data uses a “shared” key that can be decrypted after going through an identity confirmation step e.g. e-mail verification.
- Bruteforce attack - The protocol allows for user defined number of iterations / rounds for the keystretching / derivation. However this is still orders of magnitude slower than hashing the password once.
|SecReview threat brainstorming=' }}
Action Items
| Action Item Status | ` |
| Release Target | ` |
| Action Items | |
* grant jeff (jbryner@mozilla.com) and ulfr (jvehent@mozilla.com) access to 'fraud and abuse' etherpad mentioned in the wiki: https://id.etherpad.mozilla.org/fxacct-metrics-fraud-detection
Fraud and abuse meta issue: https://github.com/mozilla/fxa-auth-server/issues/222 OPSECThreat mapping What would you say are the 2-3 security/intrusion scenarios we should focus on How would you like to respond to those scenarios: --Contain and clear an intrusion --Detect and Deter active attempts --Pursue and Prosecute attackers--(Combination of any/all of the above) |
|
{{#set:|SecReview action item status=`
|Feature version=` |SecReview action items=* grant jeff (jbryner@mozilla.com) and ulfr (jvehent@mozilla.com) access to 'fraud and abuse' etherpad mentioned in the wiki: https://id.etherpad.mozilla.org/fxacct-metrics-fraud-detection
- Schedule Op meeting for fxa
- Schedule auth-server discussion with dcoates
- Schedule reviews for auth / cloud, desktop, fxos, android, attached services (end of q1 target)
Fraud and abuse meta issue: https://github.com/mozilla/fxa-auth-server/issues/222
OPSEC
Threat mapping
What would you say are the 2-3 security/intrusion scenarios we should focus on
How would you like to respond to those scenarios:
--Contain and clear an intrusion
--Detect and Deter active attempts
--Pursue and Prosecute attackers
--(Combination of any/all of the above)
}}
threat mapping (OPSEC)
What would you say are the 2-3 security/intrusion scenarios we should focus on
How would you like to respond to those scenarios:
--Contain and clear an intrusion
--Detect and Deter active attempts
--Pursue and Prosecute attackers
--(Combination of any/all of the above)
Other?
Insider Threat
endpoints used by employees are used for a variety of activities
compromise of mozilla endpoint can lead to compromize of system
Mitigations
multi factor authentication
bastion hosts
endpoint security
opsec
separation of duties
Compromise of auth server/mysql database or backups
disclosure of key data
incentive for attacker increases over time
auth server is the most privileged component
can impersonate any fx user
biggest current impact on marketplace (then sync,location)
Mitigations:
audit actions and configuration against baseline
Legal agreement with amazon re: database backup
database encryption
don't keep secrets on disk
Response:
Pursue and Prosecute along with user notification
RP notification/key rotation (currently limited RP/partners)
Online password guessing attacks
one user guessing another users account
Mitigations:
User has a security activity account page
Response:
monitor failed attempts/ip address and block/throttle
log attempts/success/failures
log pwd reset attempts/success/failures
Fraudulent account creation
create accounts via bots
Mitigations:
log account creation (meta data of click location?)
review stats after launch for further controls
Response:
Denial Of Service
prevent use of accounts by flooding requests
Mitigations:
potentially limit requests/sec at scrypt helper/auth server
potentially filter incoming requests to match only api methods
Response:
Monitor auth and scrypt helper performance stats
Log invalid api requests or over limit threshold
Security Needs
Logging
User actions are logged in, and potentially served back to the user in a dashboard. Also wanted is the ability to detect fraudulent access to an account (by geolocation, ...).
Access control
Auth server can impersonate any user.
Any security threats already considered in the design and why?
Threat Brainstorming
Action Items
Who :: What :: By When Jeff: Summarize top threats and initial response direction All: review architecture for detection/response facilitation and mitigating controls Firefox 29 ties fx accounts to sync (end of Jan in nightly), infrastructure ready in april/may