Mozilla persona

• July 14, 2011 Announcement of the start of development of BrowserID - a new identification system. ^[four]

• January 6, 2012 Integration of some Mozilla services with BrowserID for testing purposes. ^[five]

• February 22, 2012 Renaming the system. New name - Mozilla Persona, BrowserID remains the name of the open protocol only. ^[6]

• September 27, 2012 Mozilla Persona first beta released. ^[7]

Email Address as Identifier

The Persona system does not have such a thing as a login to enter the site, the user is identified using one of his email addresses. ^[8] This approach eliminates the need to remember the login for each site.

Login without password

Persona completely eliminates the need for a local password to enter the site, freeing users and sites from creating, managing and storing passwords securely. The user only needs to register once on Persona, and he will be able to go to any compatible sites without spending time on registration. ^[one]

There are three main participants in the identification process ^[9] .

1. User - a person who logs into the site using Persona.
2. The relying party is a site that provides the ability to log in using Persona.
3. Identity Provider - A domain that issues Persona-compatible identity certificates to its users.

Persona and the BrowserID protocol use their email address as the user identifier, so it is only natural that email services are usually the identity providers .

There are three main stages in the operation of the BrowserID protocol ^[9] :

1. provision of a certificate to the user,
2. statement generation
3. verification of approval.

Providing a Certificate to a User

In order for the email address to uniquely identify the user, it is necessary to establish a verifiable connection between the browser and the user's email address. To do this, you must obtain a cryptographically signed certificate from the identity provider .

Persona uses an asymmetric scheme for signing , so the certificate is signed with the private key of the identity provider . The certificate contains the following information:

1. user email address
2. the public key for this address generated by the user's browser,
3. certificate issuing time,
4. certificate expiration time,
5. Identity Provider Domain Name

For each email address, the user's browser generates its own public and private key pair, and these pairs are not transmitted in any way between different user's browsers, so the user is forced to receive a new certificate every time when it expires or when the user uses a new browser or computer.

At the moment when the user is identified on the relying party using the selected mailing address, the browser in the background checks for a certificate for this address. In the event that the browser does not have a suitable certificate, it requests a new certificate from the "identity provider".

Certificate Example

Consider the process of interaction between the user's browser and the identity provider , at the moment when Alice first uses the address alice@example.com to enter the website ^[10] .

1. The Alice browser receives a supporting document from the identity provider located at https://example.com/.well-known/browserid (inaccessible link) . This document describes how to provide a certificate, and may also contain instructions for redirecting to another identity provider .
2. The browser in the background loads a special example.com page for issuing certificates, sends it the mailbox address alice@example.com and its associated public key, requests a signature for the certificate.
3. Before signing the key, the example.com authentication provider must make sure that the initiator of the certificate request is the owner of the Alice mailing address, so the authentication provider informs her through the browser about the need for authorization .
4. The browser loads the authorization page on example.com, Alice is presented to the system, a new session is established with example.com.
5. The browser reloads the page for issuing the certificate and once again asks for the signature of the certificate.
6. On the certificate issuing page, the transmitted email address is compared with the initialization data of the session. In case of compliance, example.com signs the certificate and sends it to Alice.

Steps 3-5 can be skipped if the user has already been logged in to example.com before requesting a certificate.

Approval Generation

In order to use the certificate for identification on the “relying party”, the user must provide evidence of the ownership of this certificate for him ^[9] . To do this, the user must provide the private key from the link generated by the browser and tied to the email address to which the certificate was issued.

Before providing the private key, the user’s browser creates and signs a new document called the “Identity Approval” from the bundle with the public key. This document contains:

1. the domain name of the relying party on which the user wants to log in,
2. the expiration time of the approval.

After that, the browser sends the user certificate and the approval identifier to the relying party .

Verification of approval

Verification of approval is the process of verification by the relying party of the ownership of the mailing address to the user ^[11] .

The relying party receives a user certificate and identification approval from the user's browser ^[9] .

At the first stage of verification, the relying party works with the “approval of identification”: it checks the domain name and the expiration time of the approval. An approval is rejected if it has expired or is intended for another domain. This approach prevents malicious reuse of claims.

At the second stage of verification, the relying party verifies the signature of the statement using the public key received as part of the certificate . In the event that the public key resembles the signature of an approval, the relying party makes sure that the current user is the owner of the certificate.

At the last stage, the relying party contacts the identity provider by the domain name specified in the certificate and receives a public key from him to verify the signature of the user certificate . If the key comes to the signature, the relying party makes sure that the issuer is the one that issued it.

After successfully passing all stages of verification, the user will be able to log in to the site using the identifier contained in the certificate.

Privacy

During the identification process, the identity provider does not receive any data by which it would be possible to determine the site on which the user is authorized. Thus, the identity provider is not able to track the network activity of the user ^[12] .

Reliability

To verify the signature of a user certificate, you need the public key of the identity provider . This key is relatively constant, therefore, the relying party has the opportunity to store it in memory, giving the user the opportunity to identify using a certificate, even in a situation where there is no connection with the identity provider ^[12] .

Protection against theft or loss of a key

In order to reduce the risk of loss or misuse of a user's certificate , the validity of the certificate is limited (from several minutes to several hours). Nevertheless, the certificate cannot be canceled in any way until its validity has expired ^[13] . In addition, while an authorized session with the identity provider is active, the provider automatically supplies the user with a new certificate, after the expiration of the old one, the duration of such a session is longer than the certificate, the order of the day or even week. You can reduce the time of the established session to improve security. But you need to understand that the shorter the session, the more often the user must undergo re-authorization on the side of the identity provider . This creates certain inconvenience for the user. Some compromise is needed between safety and convenience.

No built-in phishing protection

When you try to enter the site using Mozilla Persona, a special JavaScript module displays a window for selecting and creating an identifier on the user's screen. An attacker can fake the appearance of this window in order to carry out phishing . For the user, there is only one way to detect a fake - checking the URL of this window ^[14] .

No tracking email address transfer to a new user

Email address, if not used for a long time, becomes inactive. ^[15] The email service may provide this address to another user. Since the relying party uses the email address as an identifier, the new owner of the address will be able to access all the data of the previous owner located on the site of the relying party .

1. Michael Hackett, Kirstie Hawkey. Security, Privacy and Usability Requirements for Federated Identity . - Halifax, Nova Scotia, Canada, 2012 .-- P. 1-9 . Archived January 23, 2013.
2. Harry Halpin. Web Authentication: The next step in the evolving identity eco-system? (eng.) . - Boston, USA, 2012 .-- P. 3 . Archived July 1, 2013.

• Mozilla Persona official site . Archived March 8, 2013.
• Person (Russian) .
• How BrowserID Works . Archived February 4, 2013.