Zero-knowledge password manager recovery explained

The promise of a zero-knowledge vault is that nobody but you can read what is in it. The part the sales page skips is that nobody includes the vendor’s support desk. When a teammate forgets their passphrase, there is no "reset password" email to send, because the server has nothing it could reset with. Every vendor that sells zero-knowledge has had to design a way around this, and the designs differ in who they ask you to trust. This post explains the problem, compares the common answers, and walks through exactly how Orbiz Vault does it, line by line from the code.

What zero-knowledge means for a team vault

In a zero-knowledge vault, encryption happens in your browser before anything is sent. In Vault, your master password and email are run through PBKDF2 (600,000 rounds of SHA-256, with a random salt) to derive a key. That key does not encrypt your items directly; it wraps a separate, random 256-bit vault key, and the vault key encrypts the items. The server stores the wrapped vault key, the encrypted items, and a separately derived verifier hash so it can check your password without ever learning it or the key.

Sharing works the same way. Each member has an RSA key pair, created in the browser at setup, with the private key encrypted under their vault key. To share an item, the browser encrypts it once with a fresh share key and wraps that share key for each recipient’s public key. The server relays ciphertext it cannot open. We covered the sharing model and what belongs in a collection in how to share team passwords safely; this post is about the harder half of the design.

Why recovery is the hard part

A provider cannot reset what it cannot read. 1Password’s own help page says it plainly: your account password is "never transmitted over the internet", "never known to us at 1Password" and "the only way to decrypt your data", which "means that no one can reset your password". Bitwarden describes its emergency access as a way to hand access to a trusted person "in a zero-knowledge encryption environment". The honesty is the point. If a vendor can reset your passphrase on request, it can read your vault, and so can anyone who compromises that vendor.

For a personal vault, "lose the passphrase, lose the vault" is a trade many people accept. For a company vault it is not acceptable. The credentials in it belong to the business, not to the person who typed them in, and a leaver, a lost laptop or a forgotten passphrase must not take the client’s hosting login with it. So every team vault needs a second route to the key. The catch is that a second route to the key is, by definition, a second thing that can be attacked or misused. The design question is never whether a back-up key exists, but who holds it, when it is created, and what the holder can see.

The four ways vendors solve it

Recovery codes

The simplest answer: when you set up the vault, the software generates a long random code that wraps your vault key, shows it once, and keeps only a hash of it. 1Password lets a user generate a recovery code and use it on 1Password.com to "choose a new password", after which they also get a new Secret Key. The weakness is obvious: the code lives wherever the person put it, and it does nothing for a company when that person has gone.

Emergency access and trusted contacts

Bitwarden’s emergency access is the clearest example. The account holder names trusted contacts ahead of time and chooses View (read access to every item in the individual vault) or Takeover (the contact sets a new master password, which also removes two-step login). A contact requests access; the holder approves it, or it is granted automatically once a holder-chosen wait time expires. Underneath, the holder’s symmetric key is encrypted with the contact’s RSA public key and released on approval. It is a good fit for a personal vault with a next of kin. For an organisation it needs every member to set it up individually, and Bitwarden itself points administrators to account recovery instead for offboarding.

Admin recovery

On 1Password a family organiser, a team administrator or owner, or a member of a custom group with the "Recover Accounts" permission can begin a recovery. The person receives an email, confirms their address, gets a new Secret Key and creates a new account password; they keep all their data, sign in again everywhere, and their two-factor authentication is reset. 1Password’s advice is to "make sure at least two family or team members can recover accounts", so a recovery never depends on one person.

Bitwarden’s account recovery, on its Enterprise plan, is the same idea with the mechanism spelt out: an enrolled member’s encryption key is encrypted with the organisation’s public key and stored as the Account Recovery Key. On a reset, the organisation’s private key decrypts it, the member’s key is re-encrypted under a new master key, and the server-side values are replaced. "At no point will anyone, including the administrator who executes the reset, be able to see the old master password." Enrolment, resets and the member’s password change are all logged as events.

Escrow

Escrow is the general name for what admin recovery does: a copy of each member’s key is sealed under a key the organisation holds, so an administrator can release it without the vendor ever being able to. It is the only one of the four that answers the company’s question, which is "can we get back into this vault when its owner cannot, or will not, help?" It is also the one that most needs to be read carefully, because an escrow holder can, by construction, open any enrolled vault.

How escrow recovery works in Orbiz Vault

Everything below is what the code does today, not a description of the design. The cryptography runs in the browser of whoever is acting; the server stores and relays sealed blobs.

1. An admin switches it on. The Reset Vaults page is shown to organisation Admins and Owners, and to anyone whose custom role carries the vault:reset-master-key permission. Pressing Enable admin recovery generates an RSA-2048 recovery key pair in that admin’s browser. The public key is sent to the server. The private key is wrapped for the admin’s own vault key (AES for the key itself, RSA for the AES key) and stored sealed. That admin is now the recovery holder.
2. Each member is enrolled. From then on, when a member sets up a vault, their browser wraps their 32-byte vault key with the organisation’s recovery public key and sends that one blob alongside the rest of their key material. A vault created before recovery was switched on is enrolled on its next unlock, after the member has typed the passphrase, because the vault key has to be in memory to be wrapped.
3. A member forgets. The admin unlocks their own vault, finds the member on Reset Vaults and presses Reset vault. Their browser fetches the sealed recovery private key and unwraps it with the admin’s vault private key; fetches the member’s escrow blob and decrypts it, which yields the member’s vault key; generates a one-time temporary password (twelve characters, shown once); and re-wraps the member’s vault key under that temporary password with a fresh salt and the same 600,000-round derivation. The new wrapped key and verifier replace the old ones on the server.
4. The member is back in. The admin passes the temporary password to the member, who unlocks with it and sets a new master password. Their items were never decrypted or re-encrypted, only the key that wraps them was.

What the admin sees: a temporary password they generated themselves. What the admin never sees: the member’s old passphrase, which exists nowhere. What the server never holds: a readable vault key, a readable recovery private key, or a readable passphrase. The same thing Bitwarden says about its administrator applies here.

Vault also keeps the first of the four methods. At setup, every member is shown a recovery code: sixteen random bytes as 32 hex characters, which wrap the vault key with an authenticated cipher. The server keeps a SHA-256 hash of the code so it can confirm a recovery attempt, and nothing it could derive the key from. Using the code sets a new master password and issues a new code; the old one stops working at once. A member who kept their code never needs an admin.

Questions to ask any vendor

• If I forget my passphrase, can you reset it for me? A plain "yes" means they can read your vault. The right answer names a mechanism and who holds the key.
• Who is the holder: me, a person I name, or the organisation’s admins? Each is a different threat model. A company vault needs the third.
• Does recovery have to be set up before the loss, and are existing members enrolled? Bitwarden asks members who joined before the policy to enrol; Vault enrols on the next unlock. Either way, switch it on the day the vault is created.
• What does the administrator see during a reset? The answer should be "a new credential they created", never the old one and never the items.
• How many people can recover, and what if the one who can leaves? 1Password’s advice to have at least two is right. Check the product lets you.
• Does a reset also reset two-factor? It does on 1Password, and Bitwarden’s takeover removes two-step login. That is a feature for offboarding and a risk for everything else.
• Is every reset recorded, and can I see the record? A recovery is the most powerful action in the system and should be the easiest to find afterwards.

Who this is for

Escrow recovery matters most where the credentials outlive the people: software and IT teams holding server, registry and API logins, and professional services firms that are custodians of client portals and filings. If you are a sole trader with a personal vault, a recovery code in a safe is enough and an escrow scheme is overhead. If your organisation unlocks everything through single sign-on and needs a browser extension on every machine, Vault is not there yet, and you should say so to whoever is choosing. What it does do, it does without a copy of your passphrase anywhere: the rest of how the platform is built is on the security page.