12 Restoring a user’s access to a vault

If Albert forgets or loses their Secret Key or account 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) 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 password or lost their Secret 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 Group works, it’s first necessary to understand how a group works. A group will have a key set 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 Group. 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 member; 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 Group to decrypt the contents of any vault, there are mechanisms that prevent it.

A member of the Recovery Group 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 Group 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 Group 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 Group; 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 set, \((\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 Key during this recovery signup. Carol will choose a new account 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 AUK 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 Group 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 password and Secret Key.

12.6.1 Recovery key generation

Recovery keys are generated by the client application using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG), 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) algorithm. As is the case of other secrets, such as the Secret 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) 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 HKDF 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), with the authentication subkey as the SRP-\(x\), to derive a SRP-\(v\), which is then uploaded to the server and used to authenticate 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) 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 SRP, with the authentication subkey as the SRP-\(x\), the server will authenticate the recovery key using the previously supplied SRP-\(v\).

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 set 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 authenticates 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 set symmetric key after authentication 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 Key and set a new account password, or otherwise set new root key material based on the authentication model their account uses (e.g. setting a new passkey).

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 set 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.↩︎