Password reset without a provider backdoor
If nobody but you holds your keys, nobody can reset them for you. Here is how NomadVault handles forgotten passwords and departed employees without keeping a key of its own.
Every end-to-end encrypted product has to answer one awkward question: what happens when a user forgets their password?
With ordinary cloud storage the answer is easy. The provider holds the data, so a reset is a matter of proving you are you and getting a new password. With end-to-end encryption the data is sealed with keys derived from that password, and the provider never had them. A forgotten password means the keys are gone. That is the point of the design, and it is also the problem.
Most products quietly solve it by keeping a spare key. It is called a recovery key, an admin key or a key escrow, and it lives with the vendor. It works, and it also means the “nobody but you” promise was never quite true: there is a second party that can open your files, and you have to trust that it never will, never gets compromised and never receives a court order it chooses not to fight.
NomadVault does not keep a spare key. This article explains what we do instead.
Where your password actually goes
Let’s start with what a password does in NomadVault, because the recovery design follows from it.
Your password never leaves your device. On your device it is turned, through a deliberately slow function called Argon2id, into a key. That key unlocks one thing: your Account Master Key, a random 256-bit value generated in your browser at registration. The master key in turn unlocks your identity keys, the private halves that unwrap every file, folder and group key you have access to.
The server stores only the locked boxes: the master key wrapped under your password-derived key, and the identity keys wrapped under the master key. It never sees the password, the master key or any private key. For the server, a password reset cannot mean “give the user new keys”, because it has none to give. It can only mean “wrap the existing master key under a new password”, and that step needs the master key in the clear, on a device, unlocked by something the user has.
So the question becomes: what else, besides the password, can unlock the master key?
The recovery code
When you register, your browser generates a recovery code, shows it once, and wraps your master key under it as well. The server stores that second locked box next to the first. It never sees the code.
Forgot your password? You request a reset link by email, open it, and enter the recovery code and a new password. Your browser uses the code to unlock the master key, wraps it under the new password, and sends the new box to the server. The identity keys are untouched. Your files, folders and shares are exactly as you left them, because the key that opens them never changed; only the lock on the lock was replaced.
Two consequences follow from this design.
The recovery code is yours to keep. If you lose both the password and the code, nobody can help you, including us. We show the code once, we ask you to store it somewhere safe, and we mean it. You can generate a new code at any time from your preferences, which invalidates the old one.
The reset email alone is worthless to an attacker. Many services make the email inbox the master key to everything: whoever reads your mail can reset your password and own your account. In NomadVault the link only lets you submit a new wrapped key; without the recovery code there is nothing to wrap, and a wrong code fails cryptographically on your device before anything reaches the server.
When the person is gone
A recovery code solves the individual case. It does not solve the organisational one. An employee leaves, or is unreachable, or simply never wrote the code down, and the company needs the files in that account. For a business product this is not an edge case. It is the reason most vendors keep the spare key.
Our answer is an escrow key that your organisation holds, not us.
An administrator enables escrow for the tenant and, in the browser, generates an escrow key pair. Like every key pair in NomadVault it is hybrid, RSA-4096 plus ML-KEM-768, so it is protected against future quantum attacks the same way file keys are. Both private halves are encrypted under a passphrase the administrator chooses, and that passphrase, like a user password, never leaves the device. The server stores the locked escrow keys and the public halves.
From then on, each user’s browser seals their master key to the escrow public keys and stores that additional locked box on the server. There is now a third way to unlock a master key: the user’s password, the user’s recovery code, or the organisation’s escrow key.
To recover an account, the administrator enters the escrow passphrase in their browser, unlocks the escrow private keys, unwraps the user’s master key, and wraps it under a temporary password that they hand to the user or the successor. Again, nothing on the server changes except the one locked box; the files and keys are intact.
Three details matter here.
Escrow is off by default. If you never enable it, there is no escrow key anywhere, in your tenant or ours, and account recovery is strictly recovery code or nothing. Enabling it is a conscious decision by your administrator, documented in your audit trail.
The passphrase is the key to the key. Lose it and escrow is useless; the server holds only encrypted escrow keys. Replacing the escrow key pair is possible, but users enrolled under the old pair have to be re-enrolled before they can be recovered again. Treat the passphrase like the master key of a safe: known to two people, stored in a sealed envelope, never in a chat message.
Every use is logged. An escrow recovery is a privileged act. It appears in the tamper-evident audit log with who did it, for which account, and when. An administrator cannot read a colleague’s files through escrow without leaving a record that the colleague, an auditor or a works council can inspect.
Why we think this is the right split
There is a trade-off here and we should name it. A vendor-held recovery key is convenient: one support ticket and the problem goes away. Our design puts the responsibility on you: keep your recovery code, and if you are an organisation, keep your escrow passphrase.
We think the responsibility belongs where the authority is. The organisation that owns the documents is the one that should be able to open them when a person leaves, and it should be visible when it does. The provider, who merely stores ciphertext, should not be able to open anything at all, and no policy document should be the only thing standing between your files and someone else’s decision.
That is what “end-to-end” means when it is a design rather than a promise: the hardest case, a forgotten password, is solved without anyone but you holding a key.
Questions?
If this raises a question about recovery policy in your own organisation, or your security team wants the full technical description behind this article, get in touch at hello@nomadvault.de.