4 A modern approach to authentication

1Password is an end-to-end (E2E)Data is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption system. Thus, the fundamental security of your data rests on the fact that your data is encrypted and decrypted on your local device using keys derived from your secrets which AgileBits has no access to. This E2EData is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption is the primary component of 1Password’s security. How that encryption takes place is the subject of “How vault items are secured.”

End-to-end encryption

Data is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentialityData confidentiality involves keeping data secret. Typically this is achieved by encrypting the data. and integrityPreventing or detecting tampering with the data. Typically done through authenticated encryption or message authentication. from compromises during transport or remote storage.

Nonetheless, there is an authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. component to 1Password. For the most part, its job is to ensure an individual only receives the encrypted data they should receive. “Access control enforcement” contains more details about what powers are granted to a client that successfully authenticates.

Traditionally, AgileBits has been wary of authentication-based security, and that wariness has manifested in the design of 1Password in three ways:

  1. Our overall design is fundamentally based on E2EData is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption.

  2. We’ve introduced two-secret key derivation (2SKD) to dramatically reduce the risk associated with compromise of authentication verifiers.

  3. We don’t rely on traditional authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. mechanisms, but instead use Secure Remote Password (SRP)A method for both a client and server to authenticate each other without either revealing any secrets. In the process, they also agree on an encryption key to be used for the current session. We’re using Version 6 with a modified key derivation function. to avoid most of the problems of traditional authentication.

Dangerous bend

Client authentication keys are derived from the same user secrets from which the encryption keys are derived (so you have one password for 1Password). So even though the core of 1Password’s security doesn’t depend on authentication, we must take extra care in the security of authentication so an attacker can’t work backwards from an information leak in an authentication process to discover secrets that might aid in decryption.

4.1 What we want from authentication

Your account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. and Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key. are used to derive a key that’s used for authenticating with the service we host.5 Our service needs to know that you are who you say you are. Your 1Password client needs to prove to the service it has your account password and Secret Key. Only then will it give you access to your encrypted data (which your client still must decrypt) or other administrative rights.

When Alice authenticatesThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. to Bob, she does so by proving she has access to a secret6 that only she should have access to. Bob performs some analysis or computation on the proof that Alice offers to verify it demonstrates Alice’s access to her secret.

Story 3: A very traditional authentication exchange

[ALICE approaches castle gate where BOB is on duty as a guard.]
BOB: Who goes there?
ALICE: It is I, Alice. [ALICE identifies herself.]
[BOB checks checks his list of people who are authorized to enter the castle to see if ALICE is authorized.]
BOB: What is the password? [BOB asks ALICE to prove her identity.]
ALICE: My password is xyzzy. [She provides proof.]
[BOB verifies that’s the correct password for ALICE.]
BOB: You may enter. [BOB raises the portcullis and ALICE enters.]

We want an authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. system to allow Alice to reliably authenticate herself to Bob without introducing other security problems, so there are a number of security properties we would like from a good authentication system. There’s substantial overlap among them, but they’re all technically separate.

Table 4.1: Sign-in system desiderata
Prove client ID Prove to the server the user holds the user’s secret.
Prove server ID Prove to the user the server holds the server’s secret.
Eavesdropper safe Doesn’t reveal any information about either secret in the process.
Not replayable Can’t be replayed by someone who has recorded the process and wants to repeat the exchange to fake a sign-in at another time.
No secrets received Doesn’t reveal any information about the user’s password to the server.
Session key Establishes a new secret that can be used as an encryption key for the session.
No cracking Server never acquires enough information to facilitate a password-cracking attempt.

4.1.1 Traditional authentication

With a traditional authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. system, the client (such as a web browser) sends a user secret (typically a password) to the server. The server then processes that password to determine whether or not it’s correct according to its records. If the server determines it’s correct, it will consider that user authenticated.

The simplest way to prove you know a secret is to say it, and that’s what the client does in a traditional system. It simply sends the username and the password to the server. A very traditional version of this is illustrated in Story 3.

This traditional design has a number of shortcomings. Indeed, it only satisfies the first authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. disideratum. The most glaring failures of traditional authentication include:

  • Anyone able to eavesdrop on the conversation will learn the client’s secret. In the exchange in Story 3 that would correspond to an eavesdropper hearing and learning Alice’s secret password.
  • If the client is talking to the wrong server it reveals its secret to that potentially malicious server. In Story 3, that would correspond to Bob not really being the castle guard, and Alice revealing to her password to an enemy.

In a typical internet login session, those shortcomings are addressed by Transport Layer Security (TLS)The successor to SSL. It puts the “S” in HTTPS. to keep the conversation between the client and the server private as it travels over a network and to prove the identity of the server to the client. As discussed in “Transport Security,” we make use of TLS but don’t want to rely on it.

4.1.2 Password-Authenticated Key Exchange

The modern approach to covering most of the security properties of authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. we seek is to find a way for the client and server to prove to each other they each possess the appropriate secret without either of them revealing any secrets in the process. This is done using a password-authenticated key exchange (PAKE)Password-based key exchange protocol allows for a client and server to mutually authenticate each other and establish a key for their session. It relies on either a secret each have or related secrets that each have..

Using some mathematical magic, the server and client are able to send each other puzzles that can only be solved with knowledge of the appropriate secrets, but no secrets are transmitted during the exchange. Furthermore, the puzzles are created jointly and uniquely during each session so it’s a different puzzle each time. This means that an attacker who records one authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. session will not be able to play that back in an attempt to authenticate.

The “key exchange” part of PAKEPassword-based key exchange protocol allows for a client and server to mutually authenticate each other and establish a key for their session. It relies on either a secret each have or related secrets that each have. establishes a session key: A secret encryption key that the parties can use for the life of the session to encrypt and validate their communication. With 1Password we use this session key to add an additional layer7 of encryption in our communication between client and server.

A well-designed PAKEPassword-based key exchange protocol allows for a client and server to mutually authenticate each other and establish a key for their session. It relies on either a secret each have or related secrets that each have. – we use Secure Remote Password (SRP)A method for both a client and server to authenticate each other without either revealing any secrets. In the process, they also agree on an encryption key to be used for the current session. We’re using Version 6 with a modified key derivation function., detailed in “Secure Remote Password” – can satisfy all the requirements we’ve listed except for one. On its own, a PAKE would still leave something crackable on the server, something unacceptable.

4.1.3 Making verifiers uncrackable with 2SKD

A PAKEPassword-based key exchange protocol allows for a client and server to mutually authenticate each other and establish a key for their session. It relies on either a secret each have or related secrets that each have. still doesn’t solve the problem of a server acquiring and storing information that could be used in a password cracking attempt. A server holds a long-term verifier that’s mathematically related to a long-term authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. secret used by the client. Although this verifier isn’t a password hash, it can be considered one for the sake of this immediate discussion. If the client’s long-term secret is derived from something guessable (such as a weak password), the verifier stored by the server could be used to help test guesses of that user’s password.

We can (and do) take measures to protect the verifiers we store from capture, and the client uses slow hashing techniques in generating the verifier. These are essential steps, but given the nature of what 1Password is designed to protect, we feel those steps are insufficient on their own.

We use two-secret key derivation (2SKD)Two different secrets, each with their own security properties, are used in deriving encryption and authentication keys. In 1Password, these are your account password (something you know) and your Secret Key (a high-entropy secret you have on your device). to ensure data held by the server is not sufficient to launch a password cracking attempt on a user’s account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password.. An attacker who captures server data would need to make guesses at a user’s account password and have the user’s 128-bit strong Secret KeyA randomly generated user secret key that is created upon first signup. It’s created and stored locally. Along with the user’s account password, it’s required both for decrypting data and for authenticating to the server. The Secret Key prevents an attacker who has acquired remotely stored data from attempting to guess a user’s account password. Previously known as the Account Key..

It’s for this final desideratum we introduced 2SKDTwo different secrets, each with their own security properties, are used in deriving encryption and authentication keys. In 1Password, these are your account password (something you know) and your Secret Key (a high-entropy secret you have on your device).. With this, the information held on our systems cannot be used to check whether an account password guess is correct or not. Figure 4.1 summarizes which security properties we can achieve with various authentication schemes.

Authentication schemes and what they do for you. The “+multi-factor authentication (MFA)” column lists the security properties of using traditional authentication with multifactor authentication. The “+2SKD” column lists the security properties of using a PAKE with twosecret key derivation, as done in 1Password. The first column lists our desired security properties.

Figure 4.1: Authentication schemes and what they do for you. The “+multi-factor authentication (MFA)” column lists the security properties of using traditional authentication with multifactor authentication. The “+2SKD” column lists the security properties of using a PAKE with twosecret key derivation, as done in 1Password. The first column lists our desired security properties.

Although the internals of our authenticationThe process of one entity proving its identity to another. Typically the authenticating party does this by proving to the verifier that it knows a particular secret that only the authenticator should know. system may appear to be more complex than otherwise needed for a system whose security is built upon end-to-end (E2E)Data is only encrypted or decrypted locally on the users’ devices with keys that only the end users possess. This protects the data confidentiality and integrity from compromises during transport or remote storage. encryption, we need to ensure that an attack on our authentication system doesn’t expose anything that could be used to decrypt user data. Therefore the system has been designed to be strong in its own right, and provide no information either to us or an attacker that could threaten the confidentialityData confidentiality involves keeping data secret. Typically this is achieved by encrypting the data. of user data.


  1. Your account password and Secret Key are also used to derive a different key used for the E2E, which is discussed in later sections.↩︎

  2. By broadening the definition of “secret,” we could also cover biometric authentication with this description.↩︎

  3. This layer provides authenticated encryption for the communication between client and server that is in addition to the security provided by TLS and 1Password’s fundamental E2E encryption of user data.↩︎