12 Restoring a user’s access to a vault

If Albert forgets or loses their 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. or account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password., it’s impossible to decrypt the contents of their vaults unless those vaults have been shared with someone else who hasn’t forgotten or lost the Secret Key or account password. Our use of 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). increases the risk to data availability because, in addition to the possibility of a user forgetting their account password, there’s also the possibility the Secret Key gets lost. Data loss can be catastrophic to a team, so some recovery mechanism is necessary.

Our security design also requires that we at 1Password never have the ability to decrypt your data, so we don’t have the ability to restore anyone else’s ability to decrypt their data if they have forgotten their account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password. or lost their 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.. Our solution is to place the power to recover access to vaults where it belongs: within the team.

12.1 Overview of groups

To understand how the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. works, it’s first necessary to understand how a group works. A group will have a key setHow collections of keys and their metadata are organized within 1Password. that’s similar in nature to an individual’s key set. It’s an encrypted public/private key pair. A vault is held by a group if the vault key is encrypted with the group’s public key.

Dangerous bend

An individual (or another group) is a member of the group if the group’s private key can be decrypted by that individual. To put it simply¹⁹ \(A\) is a member of group \(G\) if and only if \(G\)’s private key is encrypted with \(A\)’s public key. \(A\) can decrypt anything encrypted with her public key because she can decrypt her private key. Thus, \(A\) will be able to decrypt the private key of \(G\). With \(G\)’sprivate key, she can decrypt the vault keys that are encrypted with \(G\)’s public key. But if \(A\) hasn’t been granted access to a vault, she’ll be prevented by server policy from obtaining the vault data even though she has the key to that vault. Simple.

12.2 Recovery groups

One of the most powerful capabilities a team administrator has is the power to assign members to the team’s Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost.. In most configurations the assignment is automatic and Owners, Organizers, and Administrators will automatically be made members of the group. In 1Password Families there’s no ability to separate the roles of Owner, Administrator, and Recovery Group memberA member of a Recovery Group. See Recovery Group; they’re all wrapped up as “Organizer.” With 1Password Teams, Administrators are given more control, but not all the underlying flexibility may be exposed to the user.²⁰ This document describes recovery in terms of the Recovery Group even when the group is not exposed to the Team administrator in those terms.

12.4 Protecting vaults from recovery group members

Although there’s a chain of keys and data that would allow any member of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. to decrypt the contents of any vault, there are mechanisms that prevent it.

A member of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. won’t be granted access to the encrypted data in a vault they otherwise wouldn’t have access to, even if they can obtain the vault key.
A member of a Recovery Group will only be sent the encrypted vault keys after the user requesting recovery has re-created their account.

Thus the server prevents a member of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. from obtaining the vault keys without action on the part of the person seeking recovery. The capacity to decrypt the vault keys offers the malicious member of a recovery group little benefit if those encrypted keys are never provided. Furthermore, even if a malicious member of the recovery group can trick the server into delivering the encrypted vault keys when it shouldn’t, the attacker still needs to obtain the vault data encrypted with that key.

12.5 Recovery risks

Recovery mechanisms are inherently weak points in maintaining the secrecy of data. Although we have worked to design ours to defend against various attacks, there are special precautions that should be taken when managing a Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. or authorizing recovery.

Members of a recovery group should be adept at keeping the devices they use secure and free of malware.
Members of the recovery group should be aware of social engineering trickery.
Recovery requests should be verified independently of email. (Face to face or a phone call should be used.)
Recovery emails should be sent only if you have confidence in the security of the email system.
If there are no members of a recovery group, the capacity to recover data is lost to the team.

Figure 12.1: An overview of what keys are available to whom and when to support data recovery.

Figure 12.1 provides an overview of what data and keys are held by whom. Some hopefully irrelevant details have been omitted to keep the diagram manageable. For example, the transport encryption layers for the messages are entirely skipped (see “Transport security”) and where we speak of encrypting or decrypting private keys, it’s actually encrypting or decrypting the keys that the private parts of keys are encrypted with (see 5.1). The illustration acts as if Carol would only ever have a single vault, though of course she may create a number of different vaults.

Line 1: Our participants are Bob, a member of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost.; Carol, a member of the same team but not a member of the recovery group; and \(S\), the 1Password Server.

Line 2: Bob starts with his one personal key setHow collections of keys and their metadata are organized within 1Password., \((\pk_B, \sk_B)\), and with the private key, \(\sk_R\), of the recovery group encrypted with Bob’s public key.

Lines 3-4: Carol creates a new vault which will be encrypted using vault key \(\key_v\), which her client generates. Encrypting the items in a vault is properly described in Figure 5.1. Here we just abbreviate it as “\(\enc(\key, d_v)\)”.

Line 5: When Carol creates a vault a copy of its vault key, \(k_v\), is encrypted using the recovery group’s public key, \(\pk_R\), and sent to the server. The encrypted vault data, \(d_{ve}\), is also sent to the server for syncing and storage.

Line 6: When Bob initiates recovery (presumably after receiving a request from Carol outside of this system, as Carol can no longer sign in), Bob informs the server of his intent, and the server sends instructions to Carol by email.

Not shown in this diagram is the server putting Carol’s account into a specific suspended state. If Carol successfully signs in, the recovery is automatically cancelled.

Line 7: When Carol’s account is in a pending recovery state, she’s directed through a procedure very similar to initial signup. The key difference being that she maintains the same name, email address, and permissions instead of being treated as a new user by the system.

During this process, Carol generates a new personal key set, \((\pk_C, \sk_C)\), and shares her new public key, \(\pk_C\) with the server.

The server will inform Bob that he needs to “complete the recovery” of Carol’s account.²²

Not shown is Carol’s client generating a new 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. during this recovery signup. Carol will choose a new account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password., which may be identical to her previous one. And from her new Secret Key and potentially new account password, her client will generate a new AUKKey used to decrypt a user’s personal key set. It’s derived from the user’s account password and Secret Key. Previously known as the Master Unlock Key. with which it will encrypt her new personal key set.

Line 8: After Carol has created her new key set and Bob confirms he wishes to complete recovery, the server will send Carol’s new public key, \(\pk_C\), along with the copy of the vault key that’s encrypted with the recovery group’s key, \(R_v\). Recall that \(R_v\) was sent to the server when Carol first created the vault.

Lines 8-9: Bob can decrypt \(R_v\) and re-encrypt it as \(x\) with Carol’s new public key, \(\pk_C\) and send that to the server.

The server can then pass \(x\) back to Carol, along with the encrypted data in the vault, \(d_{ve}\).

There are several things to note about the process illustrated in Figure 12.1. Most importantly, at no time was the server capable of decrypting anyone’s data or keys. Other security features include the fact that Bob was not sent \(R_v\) until after Carol acted on recovery. The server also never sent Bob the data encrypted with \(k_v\). The server would have canceled recovery if Carol successfully authenticated using her old credentials, thus somewhat reducing the opportunity for a malicious recovery without Carol noticing. Nonetheless, it remains possible that a malicious member of a recovery group who gains control of Carol’s email could come to control Carol’s 1Password account.

12.6 Recovery keys

Recovery keys are a mechanism for allowing a user to recover their account without the need for a member of the Recovery GroupThe 1Password Group that has a copy of the vault keys for vaults that may need to be recovered if account passwords or Secret Keys are lost. to be involved. This is particularly useful for accounts with a single user or in the case of a family organizer, where there may not be another user available to perform recovery using the method described above. We designed this mechanism to minimize the risk of these keys being used to enable an attacker to take over an account, thus providing greater safety than a user backing up their 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..

12.6.1 Recovery key generation

Recovery keys are generated by the client application using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)A random number generator whose output is indistinguishable from truly random. Despite “pseudo” in the name, a CSPRNG is entirely appropriate for generating cryptographic keys., with a length of 32 bytes. Following generation, the recovery key is encrypted using the user’s key set symmetric key, and stored on the 1Password server. It’s stored to allow the use of the key without regeneration or redistribution should the user’s key set be rotated, or cryptographic components upgraded, such as the 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. algorithm. As is the case of other secrets, such as the 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., recovery keys are never exposed to the 1Password servers in unencrypted form.

Three subkeys are then generated using a hash-based key derivation function (HKDF)A key derivation function that uses HMAC for key extraction and expansion. Unlike PBKDF2, it’s not designed for password strengthening. with the recovery key as the input keying material, and the following information values:

1P\_RECOVERY\_KEY\_AUTH\_v1: Authentication subkey – 32 bytes, used to authenticate the recovery key via a PAKE, to ensure the correct key is being used without exposing the key itself.
1P\_RECOVERY\_KEY\_ENC\_v1: Encryption subkey – 32 bytes, used to encrypt the user’s key set symmetric key, allowing the user to decrypt their key set and recover their account.
1P\_RECOVERY\_KEY\_UUID: Identifier - 16 bytes, used to identify the recovery key. This is a non-secret value, used by the server to identify the correct recovery key to use when multiple keys are available.

The HKDFA key derivation function that uses HMAC for key extraction and expansion. Unlike PBKDF2, it’s not designed for password strengthening. is used to ensure the subkeys are independent of each other, and recovery key is not exposed. Using the encryption subkey, the user’s key set symmetric key is encrypted by the client application, and uploaded to the 1Password server. In addition, the client application uses 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., with the authentication subkey as the SRP-\(x\)The client secret, 𝑥, used by the Secure Remote Password (SRP) protocol. Derived from the user’s account password and Secret Key., to derive a SRP-\(v\)The Secure Remote Password (SRP) verifier, 𝑣, used by the server to authenticate the client., which is then uploaded to the server and used to authenticateThe 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. the recovery key to the server.

12.6.2 Recovery key authentication

When a user wants to recover their account, they must complete the following steps:

The client application will derive the identifier subkey from the recovery key, supplying it to the server.
The server will return the cryptography version number of the recovery key, and any 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. parameters required to authenticate the recovery key.
The client application will derive the encryption and authentication subkeys from the recovery key, and use the authentication subkey to authenticate the recovery key to the server. This occurs with the client application using SRPA 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., with the authentication subkey as the SRP-\(x\)The client secret, 𝑥, used by the Secure Remote Password (SRP) protocol. Derived from the user’s account password and Secret Key., the server will authenticate the recovery key using the previously supplied SRP-\(v\)The Secure Remote Password (SRP) verifier, 𝑣, used by the server to authenticate the client..

Upon successful completion of these steps, the recovery key is authenticated and the client application can proceed with recovery.

12.6.3 Recovery key policies

A recovery key may implement a policy to control how it can be used. This is selected by the user when the key is generated, and stored alongside the key on the server. These policies allow additional controls to be added, beyond simple possession of the key, to ensure the user is authorized to use the key. The server won’t provide the encrypted key setHow collections of keys and their metadata are organized within 1Password. symmetric key to the client application until all policies are satisfied.

In addition to the polices applied as part of the recovery key itself, the server may also apply additional policies to the recovery process, this includes (at a minimum):

Recovery is aborted if the user successfully 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. during the recovery process.
Recovery is aborted if the user has successfully authenticated during the prior hour.
Recovery is aborted if the recovery key had an aborted attempt in the prior 24 hours.

12.6.4 Recovery key use

The server will return the encrypted key setHow collections of keys and their metadata are organized within 1Password. symmetric key after 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. is complete and all recovery policies complied with. The client application can decrypt it using the encryption subkey, allowing the user to regain access to their key set. The user will then be able to regenerate their 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. and set a new account passwordSomething you must remember and type when unlocking 1Password. It’s never transmitted from your devices. Previously known as Master Password., or otherwise set new root key material based on the 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. model their account uses (e.g. setting a new passkeyA credential with which you authenticate to a server. Unlike a password, the passkey isn’t sent to the server to authenticate. Instead, the passkey signs a challenge the server provides to your device. This process is also known as WebAuthn or FIDO2 authentication.).

12.6.5 Recovery codes

Recovery codes are an implementation of recovery keys, with a policy applied to require email verification before the recovery key can be used. As such, when a user want to recover access to their account with a recovery code, they must verify their email address, then complete the recovery process as described above.

If the user can’t verify control of their email address, the server won’t provide the encrypted key setHow collections of keys and their metadata are organized within 1Password. symmetric key to the client application, and the recovery process will be aborted.

For some values of the word “simply.”↩︎
We discovered during our beta testing that it was difficult to make the distinction between Owners, Administrators, vault Managers, and Recovery Group members clear enough for those distinctions to be sufficiently useful.↩︎
1Password Teams also have a permission called Manage All Groups that has equivalent cryptographic access, which is only given to the Administrators and Owners groups by default.↩︎
This would be a good time for Bob to confirm with Carol through some method other than email that it’s indeed Carol who has reestablished her account.↩︎