Security/Reviews/Identity/browserid
From MozillaWiki
Contents
Status
| Identity (browserid) | |
|---|---|
| Tracker Bug | - |
| Stage | Definition |
| Status | Red (Green, Yellow, Red?) |
| Release Target | Live |
| Health | - |
| Status Note | Demo is live, secreview is underway |
Team
| Product manager | Dan Mills |
| Feature manager | - |
| Engineering lead | Ben Adida |
| Infrastructure Security lead | Yvan Boily |
| Product Security lead | Sid Stamm |
| Privacy lead | Sid Stamm |
| Localization lead | - |
| Accessibility lead | - |
| QA lead | - |
| UX lead | - |
| Product marketing lead | - |
| Additional members | - |
Open issues/risks
Stage 1: Definition
Introduction
Include brief summary of feature/project, and link back to core feature/product pages.
Use Cases
Data Flows
Diagram
1. Provisioning
| ID | Origin | Destination | Description |
| 1.A | Relying Party | Implementation Provider | An interaction with the Relying party invokes the Implementation Provider (IP). |
| 1.B | Implementation Provider | Identity Authority | The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent. |
| 1.C | Identity Authority | Identity Authority | Code from the IP landing page invokes genKeyPair() to generate a keypair. |
| 1.D | Identity Authority | Implementation Provider | The IP saves the keypair in the client |
| 1.E | Implementation Provider | Implementation Provider | genKeyPair() returns the public key component to the IA |
| 1.F | Implementation Provider | Identity Authority | The IA generates an id bundle |
| 1.G | Identity Authority | Identity Authority | The IA saves the public key to the server in a secure fashion. |
| 1.H | Identity Authority | Identity Authority | The IA generates a signed verified email object that can be used to generate assertions. |
| 1.I | Identity Authority | Identity Authority | The IA calls registerVerifiedEmail with the signed object, which will be saved in the client keyring. |
| 1.J | Identity Authority | Implementation Provider | The IA proceeds to generate an assertion (2.2) |
2. Assertion Generation
| ID | Origin | Destination | Description |
| 2.A | Relying Party | Implementation Provider | An interaction with the Relying party invokes the Implementation Provider (IP). |
| 2.B | Implementation Provider | Implementation Provider | If the IP has no stored verified emails, then redirect to the provisioning process |
| 2.C | Implementation Provider | Implementation Provider | If there are stored verified emails, the IP will present a list of registered identities. |
| 2.D | Implementation Provider | Implementation Provider | Once the user has selected an identity an authentication bundle is generated and then signed with the private key associated with the identity. |
| 2.E | Implementation Provider | Implementation Provider | The IP returns the signed verified email bundle to the RP. |
3. Assertion Verification
| ID | Origin | Destination | Description |
| 3.A | Relying Party | Relying Party | The assertion is forwarded from the client to the server. |
| 3.B | Relying Party | Relying Party | The assertion was not issued by a Secondary Implementation authority, so the domain is extracted from the identity to determine the location of the certificate for the issuing IA. |
| 3.C | Relying Party | Identity Authority | The assertion was issued by a Secondary Implementation authority, so the certificate is loaded from the address specified in the issued-by field of the assertion. |
| 3.D | Relying Party | Relying Party | If the signature is valid, the assertion has been generated correctly and can be accepted by the Relying Party. |
| 3.E | Relying Party | Relying Party | An error has occurred in the verification of the assertion, so the assertion is rejected. |
Architecture Diagram
Stage 2: Design
Threat Model
| ID | Title | Threat | Proposed Mitigations | Threat Agent | Rating | Likelihood | Notes | Impact | Notes |
| 1 | SIA may introduce compliance issues | Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information | Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process. | Governments, Lawyers | 12 | 3 | Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk. | 4 – Reputation | Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press. |
| 2 | Webfinger Information Leak | Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority | Implement verification using certificates | Malicious Identity Authority | 25 | 5 | This information disclosure is a part of the protocol. | 5 – Privacy | This is probably a clear violation of our privacy policies. |
| 3 | Chrome Code Injection | Attacker controlled parameters could permit injection of script into browser chrome. | Ensure that any data controlled by the user or relying party is emitted using output encoding. | Malicious Relying Party, Malicious User, Malicious Identity Authority | 4 | 1 | Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS. | 4 – User | This gives an attacker the ability to execute code in the context of browser chrome. |
| 4 | Cross Site Scripting (content) | Attacker controlled parameters could permit injection of script into the BrowserID.org supplied implementation | Implement Content Security Policy for all components of BrowserID.org. Ensure that any data controlled by the user or relying party that is rendered by BrowserID is emitted using out put encoding. | Malicious Relying Party. Malicious User | 6 | 2 | Code review and testing should prevent this occuring. | 3 – User | This allows an attacker to acquire specific information about the authenticated account, such as the email addresses they use. |
| 5 | User Enumeration | A malicious user with a list of email addresses can call /wsapi/have_email to enumerate enrolled addresses. | Rate limit requests to have_email to a reasonable number, and require a CAPTCHA or other mechanism when that number is exceeded. | Malicious User | 15 | 5 | This is a requirement of the enrollment process for Browserid.org | 3 – Reputation | There may be negative comments from users |
| 6 | Compromise of Identity Certificate | If an attacker can acquire the keypair stored by the browser an attacker can forge authentication requests. | The keys stored in local storage should be protected within local storage, for example, encrypted with the master password or some other method. | Skilled Attacker, Governments | 10 | 2 | The attacker would have to find a way to gain control over the browser chrome, or compromise the target computer. | 5 – User | Although it doesn\'t give control over the user\'s device, it does give control over the user\'s identity in relation to authorized services. |
| 7 | MITM – Attacker Between RP and BrowserID.org | If an attacker is able successfully launch an MITM between the RP and BrowserID.org, the attacker will be able to launch XSS against the RP (include.js) and control how users enroll with BrowserID. | Implementing STS and CSP will mitigate much of the risk here. Strong change control processes will become more critical as the number of relying parties using BrowserID.org grows. | Skilled Attacker, Governments, Network Operators | 8 | 2 | 3 – User
4 - Reputation 3 - Operational||Although some specific personal information might be lost, and there might be operational implications, the reputational impact would likely be severe if the cause was something we could prevent. | ||
| 8 | MITM – Attacker between RP and IA | In cases where the RP talks to the Identity Authority (Webfinger, or other interactions), a successful MITM can allow an attacker to forge verification responses, and can enumerate users of the IA who are also using the RP. | This is beyond our control. Identity Authorities should implement support for CSP to reduce the likelihood of an XSS attack that could impact how the API are used, and STS to ensure that TLS is enforced. | Skilled Attacker, Governments, Network Operators | 6 | 2 | 3 – Reputation | Despite the fact that this is beyond our control, this would still be a consideration and it would reflect negatively on us until the protocol achieves mainstream acceptance. | |
| 9 | MITM – Attacker between chrome IP and IA | If an attacker is able to acquire control over events or objects within the browser that control the browserid protocol implementation, an malicious extension could introduce weaknesses or break the security (e.g. Forwarding keys to 3rd parties) | Ensure that the browserid implementation is secure against tampering from extensions and other components. | Skilled Attacker, Malicious Add-on Author | 9 | 3 | This needs more input from the client security team. | 3 – User | Users who install add-ons or extensions are already giving up a certain degree of control. This is almost as severe as giving up the credentials for the email identity associated with it, although the scope of the impact is limited to authorized sites. |
| 10 | Compromise of IA Certificates | If an attacker can acquire the keypair used to sign user certificates, the attacker forge a component of the authentication tokens. | This is beyond our control, but we should maintain revocation lists and implement the ability to block/blacklist PIAs. | Skilled Attacker, Malicious Administrator | 9 | 3 | As PIAs proliferate, depending on how discoverability is implemented it is likely someone will fail to secure things properly. | 3 – Engineering | This doesn\'t give the ability to forge the entire authentication process, but it gives an important step. As PIAs implement the alternative to webfinger when it emerges, this will need to be considered. |
User Interactions
| ID | Summary | Description |
| 1.A | Navigate to Relying Party | |
| 1.B | Click Sign In | Redirect to 2.B, return to application specific behaviour when an assertion is recieved. |
| 1.C | Click Logout | Application specific behaviour |
| 1.D | Wait for User Interaction | This is the user interface presented either in the BrowserID Dialog after enrollment, or in the Manage user interface loaded off of the browserid website. |
| 1.E | Select Email Address | |
| 1.F | Add Email Address | Selected from within the BrowserID dialog to associate an additional email address to the currently authenticated account. |
| 1.G | Select \"This is not me\" | Redirects to the authentication interface and calls to 3.I |
| 1.H | Visit prove link from verification email | When browserid.org issues a verification email, the link should be opened in a new window. After the user\'s email is verified the browser will navigate to the /manage interface; from here a user can perform other actions. Note: The prove link does not authenticate a user, therefore if the link is followed in a browser that doesn\'t have an authenticated session the manage interface from 1.L is rendered, or another session if the browser has an authenticated session for another user. |
| 1.I | Authenticated user navigates to Manage page | |
| 1.J | Select Forget Email | Break the association between an email address and an authenticated account. |
| 1.K | Select Cancel Account | Remove all email addresses from the authenticated account. |
| 1.L | Unauthenticated user navigates to Manage Page | The current interaction loads a non-functional page. This should redirect to an authentication/enrollment page. |
Client Interactions
| ID | Summary | Description |
| 2.A | Load include.js | This call loads include.js from browserid.org and adds the navigator.id.getVerifiedEmail() api. |
| 2.B | Call getVerifiedEmail() | This call invokes the user interface for authenticating, enrolling, and selecting a verified email. |
Server Interactions
| ID | Summary | Description | Path | Input | Output | CEF | CSRF |
| 3.A | Check if user is authenticated | /wsapi/am_authed | true/false | ||||
| 3.B | Perform Authentication | /wsapi/authenticate_user | csrf, email, pass | true/false | Y | ||
| 3.C | Check if email is enrolled | /wsapi/have_email | email_address | true/false | Y | ||
| 3.D | Stage User | /wsapi/stage_user | csrf, email, pass, pubkey, site | true/exception | Y | Y | |
| 3.E | Registration Status | Poll to notify the browserid dialog when the user has confirmed an address. | /wsapi/registration_status | pending/complete | |||
| 3.F | Pull list of email addresses | Synchronizes the list of email addresses between the client and browserid.org so that the current and valid emails are the only ones displayed. | /wsapi/sync_emails | csrf, emails | JSON Object | Y | Y |
| 3.G | Push list of public keys for known email addresses | Sets the public key for the keypair generated by the client on the browserid server. | /wsapi/set_key | csrf, email, pubkey | Y | Y | |
| 3.H | Add new email to account | /wsapi/add_email | csrf, email, pubkey, site | true/exception | Y | Y | |
| 3.I | Clear active session | Clearing the active session only destroys the session as stored on the server; the keychain stored in the browsers local storage is intact. | /wsapi/logout | csrf | ok | Y | Y |
| 3.J | Submit prove token to complete account creation | /wsapi/prove_email_ownership | token | true/false | Y | ||
| 3.K | Delete email from account | /wsapi/remove_email | csrf, email | true/exception | Y | Y | |
| 3.L | Delete entire account | /wsapi/account_cancel | csrf | true/exception | Y | Y | |
CEF and CSRF columns indicate wether or not CEF logging or CSRF prevention is required for the interactions
Security Recommendations / Open Issues
| ID | Title | Status | Summary |
| [[1]] | Implement CSP | Open | Content Security Policy should be implemented for all aspects of BrowserID. This will eliminate most, if not all, XSS related threats. |
| [[2]] | Implement X-Frame-Options | Complete | Implementing X-Frame-Options to control how content can be loaded in iframes will prevent a range of click-jacking attacks. |
| [[3]] | Implement STS | Complete | Strict Transport Security will prevent users and relying parties from accidentally using non-https urls. |
| [[4]] | Implement Secure Cookie Attributes | Complete | Implement httponly/secure attributes to mitigate cookie related risk. |
| [[5]] | Implement Ratelimiting for have_email API | Open | Implement rate limiting for HTTP requests |
| 671996 | Implement CEF Logging | Open | Implement CEF Logging, and implement the specific CEF logging points in the next section. |
| 674769 | Prevent overwriting of account associations | Wont fix | Users can add an email to an existing account and override pre-existing account associations. |
| 674774 | Update verification process | Complete | Logout when a user clicks prove-email and the auth\'d account is not one owned by the user who just proved |
CEF Logging Requirements
Business Test Cases
Document application specific test cases here
Privacy Risk Analysis
(Status of and link to privacy review and outcome here)
Stage 3: Planning
Application Security Requirements
Document individual requirements for the application here (e.g. CEF logging, captcha, etc)
Operation Security Requirements
Document network/platform security requirements here (e.g. IDS concerns, firewall changes, system hardening reqs, etc)
Mana Website Creation Form
Critical Security Requirements
Itemize individual security blockers here. Reference components in section AppSec or OpSec subsections. These blockers must be addressed before the product can go live.
Stage 4: Development
Repeatable Security Test Cases
Document individual repeatable security test cases here. Include a reference to the source repo, and documentation that governs how to execute test cases.
Secure Coding Guidelines
Document specific secure coding guidelines to be followed and relate them to specific issues/requirements that are specified; capture bug ids related to those issues.
Code Review Milestones
Table 1 - itemized list of code review milestones {i.e. breakdown of specific components that will be reviewed} Table 2 - list of app components/modules that should trigger additional security review (e.g. auth, csrf, file upload handling, etc)
Stage 5: Release
Application Security Verification
These subsections should contain a list of the steps to be taken, and the status of each activity
Code Review
Automated Security Testing
Manual Security Testing
Operational Security Verification
ArcSight Information
Network Design Security Review
Database Security Review
Platform Security (Hardening & Specific Config Requirements)
Landing Criteria
This should be a table itemizing everything from Stage 3 - Critical Security Requirements, including status. For status Red=Unimplemented,Yellow=implemented,Green=tested and passed?
Stage 6: Post Implementation Review
Production Security Considerations
Document additional/ongoing work for this application (e.g. specific things to watch for in ArcSight, gaming behaviour, etc)
Post Implementation Tasks
Itemize process/kb changes developed from this project (e.g. secure coding guidelines, policy stuff, etc)
Team status notes
| status | notes | |
|---|---|---|
| Products | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
