Security/Reviews/Accounts Sync

Item Reviewed

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
  • https://docs.google.com/a/mozilla.com/document/d/1yABCKB78WImt5o4GGt2FBCbsRkn4Z13rYg0mehuA4LM/edit

• 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

'

Action Items

   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  

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