Password-Derived Keys and the No-Reset Tradeoff

Every zero-knowledge service faces the same uncomfortable question from new users: "What happens if I forget my password?"

The honest answer is: your data is gone.

Not because we're lazy. Not because we haven't thought about it. Because the math demands it. If we could reset your password, we could read your files — and the entire zero-knowledge promise collapses.

This post breaks down exactly how password-derived encryption keys work, why the no-reset tradeoff is cryptographically unavoidable, and how we design around it without compromising security.

How Password-Derived Keys Work

When you create a BitAtlas account, your password never leaves your browser. Instead, it becomes the seed for your master encryption key through a process called key derivation.

Here's the simplified flow:

password + salt → PBKDF2(600,000 iterations) → 256-bit master key

The key derivation function (KDF) takes your password and a unique, random salt, then applies the PBKDF2-HMAC-SHA256 algorithm hundreds of thousands of times. Each iteration feeds the output of the previous round back in, creating a computational chain that's expensive to brute-force but trivial to compute once when you know the password.

The result is a 256-bit AES key — your master key. This key never touches our servers. It exists only in your browser's memory while your session is active.

The Key Hierarchy

Your master key doesn't encrypt files directly. Instead, BitAtlas uses a key hierarchy:

1. Master key — derived from your password via PBKDF2
2. Per-file keys — random 256-bit AES-GCM keys generated for each file
3. Wrapped keys — each per-file key encrypted (wrapped) with your master key

When you upload a file, your browser:

• Generates a random AES-256-GCM key for that specific file
• Encrypts the file content with the per-file key
• Wraps (encrypts) the per-file key with your master key
• Sends the encrypted file and the wrapped key to the server

The server stores two opaque blobs: encrypted content and a wrapped key. Without your master key, neither is useful.

Why We Can't Reset Your Password

Here's the critical chain of dependencies:

password → master key → unwraps per-file keys → decrypts files

If you lose your password, you lose the ability to derive the master key. Without the master key, the wrapped per-file keys are just random noise. Without the per-file keys, your encrypted files are indistinguishable from random data.

There is no backdoor. There is no recovery email flow. There is no "security question" that magically regenerates a 256-bit key from your mother's maiden name.

"But What If You Store a Recovery Key on the Server?"

This is the most common suggestion, and it fundamentally breaks the zero-knowledge model. If the server holds a recovery key (or an escrow copy of your master key), then:

• The server can decrypt your files at any time
• A compromised server means compromised data
• A government subpoena can compel access
• An insider threat has full access

You're back to "encryption at rest" — the model where the provider encrypts your data with their key and pinky-promises not to look. That's Dropbox, Google Drive, and every other conventional cloud provider.

The entire point of zero-knowledge is that we are technically incapable of accessing your data. Not "we choose not to." Not "our policy says we won't." We can't. The math prevents it.

"What About Storing an Encrypted Recovery Key on the Server?"

A more sophisticated suggestion: encrypt a copy of the master key with a separate recovery passphrase, store that on the server. The user remembers two secrets instead of one.

This does work in theory — and some services like 1Password implement a variant with their Secret Key. But it shifts the problem rather than solving it: now you need to securely store two secrets. If you lose both, your data is still gone. And the second secret creates a second attack surface.

At BitAtlas, we chose simplicity: one password, one key, one responsibility. No illusion of a safety net that might give users a false sense of security.

The PBKDF2 Parameters Matter

Not all key derivation is equal. The security of password-derived keys depends heavily on the KDF parameters:

Iteration Count

PBKDF2's iteration count determines how expensive it is to test a single password guess. At 600,000 iterations of HMAC-SHA256:

• A legitimate user waits ~200-400ms to derive their key (once, at login)
• An attacker testing billions of passwords pays that cost for every single guess

This is the core asymmetry that makes password-derived crypto viable. The defender pays the cost once; the attacker pays it billions of times.

Salt

Each account gets a unique random salt (128 bits). This prevents:

• Rainbow table attacks — precomputed tables are useless because every salt produces different output
• Multi-target attacks — cracking one user's password doesn't help with another's

Why Not Argon2?

Argon2 (specifically Argon2id) is considered the state-of-the-art KDF. It's memory-hard, meaning attackers can't just throw GPUs at it — they need significant RAM per guess, which is expensive to parallelize.

PBKDF2 is CPU-hard but not memory-hard. So why do we use it?

Pragmatism. The Web Crypto API — the browser's native cryptography interface — supports PBKDF2 natively but does not yet support Argon2. Using a JavaScript Argon2 implementation would be slower, harder to audit, and couldn't leverage hardware acceleration.

When browser vendors add native Argon2 support (and the proposal is in progress), we'll migrate. Until then, PBKDF2 with a high iteration count and enforced password complexity provides strong protection for the vast majority of threat models.

Designing UX Around Irreversibility

Accepting the no-reset tradeoff doesn't mean ignoring it. Good UX means making sure users understand the stakes before they're locked out.

What BitAtlas Does

1. Clear onboarding warnings — During signup, we explicitly state: "If you lose your password, we cannot recover your data. This is by design."

2. Password strength enforcement — We require passwords with sufficient entropy. A weak password with 600,000 PBKDF2 iterations is still a weak password.

3. Recovery key export — Users can export a recovery key (a base64-encoded copy of their derived master key) to store in a password manager, safe, or printed on paper. This is a client-side operation — the recovery key never touches our servers.

4. Session persistence — Active sessions use derived key material cached in memory, so you're not re-entering your password constantly. Balance between convenience and the risk of session hijacking.

What Users Should Do

• Use a password manager. This eliminates the "forgot my password" scenario for 99% of users. Your password manager remembers the password; PBKDF2 derives the key; your files stay safe.
• Export and store the recovery key. Treat it like a hardware wallet seed phrase: write it down, store it offline, never share it.
• Understand the stakes. Zero-knowledge encryption is powerful because it's absolute. That absoluteness cuts both ways.

The Broader Principle: Security Through Inability

The no-reset tradeoff is an instance of a broader design principle: the most trustworthy systems are those that are technically incapable of betraying you.

You don't need to trust BitAtlas's privacy policy. You don't need to trust our employees. You don't need to trust our hosting provider. The encryption runs in your browser. The key lives in your head (and your password manager). The server stores ciphertext.

This is what separates zero-knowledge from "trust me" encryption. And the password reset button — or rather, its absence — is the clearest signal of which model a service actually uses.

If a service offers zero-knowledge encryption and password reset, one of those claims is false.

Wrapping Up

Password-derived keys are the foundation of zero-knowledge architecture. PBKDF2 transforms a human-memorable password into a cryptographically strong key. The key hierarchy ensures each file has unique encryption. And the no-reset policy isn't a missing feature — it's proof that the system works as advertised.

The tradeoff is real: lose your password, lose your data. But the alternative — a service that can always "help" you recover access — is a service that can always access your data without your permission.

We'll take the tradeoff.

---

Want to see how this works in practice? BitAtlas is open source — inspect the client-side encryption implementation yourself at github.com/bitatlas-group/bitatlas. Or try bitatlas.com and watch the encryption happen in your browser's DevTools.