Personal tools

Security/Reviews/Identity/browserid

From MozillaWiki

Jump to: navigation, search

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

BrowserID-Protocol.png

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.
BrowserId.org Implementation Dataflow

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 -