Why We Don’t Offer “Reset Password by Email”

Short answer: resetting an account by sending a magic link to an email address hands control of your account to whoever controls that inbox. Email is convenient, but it is also a weak link that can be compromised in many ways. We choose stronger, user-controlled recovery methods instead.

Why people like email resets

• Fast and familiar: it is simple for users and reduces support friction.

Why email resets are risky

• If your email is compromised, so is your account. Attackers who control an inbox can click a reset link and take over everything.
• SIM swap and account recovery attacks. Phone carrier or email recovery mechanisms are often weaker than the service they protect.
• Magic links are equivalent to passwords. A one-click token that grants account access is, in practice, a password that lives in your email.
• Email providers store or index messages. Your reset tokens can end up in backups, logs, or subject to legal process.
• Phishing and malicious forwarders. A malicious app or rogue forwarder can exfiltrate magic links.

If you want a secure account, you cannot rely on the security model of someone else’s inbox.

Why we refused easy convenience

Offering email reset would lower the minimum security bar for all users and create easy attack paths. We prefer to keep account recovery user-controlled and cryptographically grounded.

What we do instead

• OPAQUE-based authentication. A password-authenticated key exchange so the server never stores password-equivalent data.
• Passkeys and WebAuthn. Passwordless, phishing-resistant authentication that reduces attack surface.
• Client-generated 12-word seed phrase for recovery. During registration we show a 12-word mnemonic on the Auth page’s Backup step. These words are the only way to reset a lost password. The seed is generated client-side, shown once, and you should store it offline. If you still know your password, you can change it in your dashboard as usual.
• Trusted-device recovery and protections. Trusted devices can assist in re-encrypting and restoring access. We also use rate limiting and human review for suspicious recovery attempts.

This approach gives you a recoverable account without relying on someone else’s email security, while keeping recovery client-side and preserving zero-knowledge, end-to-end encryption.

The trade-offs

• This approach adds some friction when you lose access to everything, but it avoids a world where email compromise equals account compromise.
• We trade a tiny bit of convenience for a much stronger security posture for everyone.

Questions to ask other providers

• Do you allow reset-by-email and what protections stop an attacker who controls an inbox?
• Do they support passkeys, OPAQUE, or a client-side seed-based recovery flow?

What not to promise: “We never need recovery” or “We can always recover your account”. Those claims either mean the provider can read your secrets or they will lock you out.

For crypto nerds

• Why OPAQUE: OPAQUE is a password-authenticated key exchange. The server stores an opaque envelope that cannot be used on its own to impersonate a user. Authentication uses an OPRF and yields an authenticated session key without revealing the password to the server.
• Why no magic links: A reset token is a bearer token. If an attacker intercepts or steals it, they can take over the account without cracking anything.

How seed-based recovery works (double-wrapped master key)

We use a double-wrapping approach so the mnemonic alone can restore your account without ever exposing your master key to the server:

1. The user records a client-generated 12-word mnemonic at the Auth page’s Backup step.
2. The client derives a Recovery Key Encryption Key (RKEK) from the mnemonic (we hash the mnemonic to derive a 32-byte key).
3. A random 32-byte Recovery Key (RK) is generated and encrypted with RKEK. The encrypted RK and its nonce are stored on the server.
4. The Master Key (MK) is encrypted with RK and the encrypted MK and its nonce are also stored on the server.

On recovery, the client uses the mnemonic to derive RKEK, decrypts the encrypted RK with RKEK, then decrypts the encrypted MK with RK. The client now has MK and can re-derive all local keys and regain access. At no point are plaintext MK or RK sent to the server.

Here is a tiny, high-level snippet showing the flow (illustrative only):

1
// derive RKEK from mnemonic (double SHA-256 in our implementation)
2
const rkek = await deriveRecoveryKeyEncryptionKey(mnemonic);
3

4
// fetch encryptedRecoveryKey and nonce from server
5
const { encryptedRecoveryKey, recoveryKeyNonce } = await fetchEncryptedRK();
6

7
// decrypt RK using RKEK
8
const rk = decryptRecoveryKey(encryptedRecoveryKey, recoveryKeyNonce, rkek);
9

10
// fetch encrypted Master Key and nonce
11
const { encryptedMasterKey, masterKeyNonce } = await fetchEncryptedMK();
12

13
// decrypt MK using RK
14
const mk = decryptMasterKeyWithRecoveryKey(encryptedMasterKey, masterKeyNonce, rk);

This design lets you recover a lost password while keeping a zero-knowledge, end-to-end encrypted model.

Fact check notes: we use XChaCha20-Poly1305 for symmetric encryption and 24-byte nonces. We derive RKEK from the mnemonic (the example here uses a double SHA-256 to produce 32 bytes). RK and MK are 32-byte keys and are randomly generated.