Recovery Code Vault

Why Store Backup Codes?

Backup codes are your safety net when you lose access to your authenticator app. Every service that offers 2FA provides backup codes at setup — but most people never save them, and many have been locked out of accounts permanently as a result.

This vault gives you a dedicated, encrypted place to store backup codes. Unlike a plain notes app or a text file, your codes here are encrypted — even if someone accesses your device, they cannot read your backup codes without your vault password.

Encrypted Vault vs. Plaintext Storage

The most common way to keep backup codes is a notes app, a desktop text file, or a screenshot sitting in the cloud. None of those are encrypted, and that matters more than people realize: a backup code is a long-lived credential. A normal authenticator code expires after 30 seconds, but a recovery code stays valid until it is used, which makes it a much more valuable target than code that changes every half minute.

This vault inverts that risk model. Every entry is encrypted in your browser with AES-256-GCM, and the key is derived from your passphrase using PBKDF2 with 100,000 iterations. What gets written to storage is ciphertext only — without the passphrase, it is unreadable even to someone with full access to the device, the browser profile, or the stored data itself. The vault runs entirely in your browser: no account, no server, no sync, nothing ever leaves the page.

Choose the passphrase with intent

The passphrase is the only key, and by design it cannot be reset. That is exactly the property you want: it means nobody else can reset it either. Use a long, unique phrase (three or four random words), store it in your password manager, and avoid anything that appears in breach lists. A weak phrase weakens the entire encryption, so the passphrase deserves the same care as the codes themselves.

Where recovery codes actually come in

Recovery codes are issued once, when you enable 2FA on an account, and most services show them a single single time on the setup screen. They exist for the day your phone breaks, your authenticator app gets wiped, or you get a new device before transferring the codes. Because each code is usually single-use, you should store them intact and remove a code from the list as soon as it is consumed. Keeping them in one encrypted, searchable place — labeled by service name — turns a potential lockout into a two-minute fix.

Threat Model & Design Assumptions

This vault is designed for the following threat scenarios:

• Device theft or loss — an attacker with physical access to your laptop/phone cannot decrypt the vault without the passphrase.
• Browser profile compromise — malware reading localStorage sees only ciphertext; the passphrase never touches storage.
• Cloud sync leakage — if your browser syncs localStorage (e.g., Chrome Sync), the encrypted blob is what syncs. The passphrase stays in your head/password manager.

What this vault does not protect against:

• Keyloggers or clipboard monitors — if malware captures your passphrase or the decrypted codes at the moment you view them, encryption cannot help.
• Shoulder surfing — codes are displayed in plaintext when you unlock the vault.
• Device compromise before vault creation — if the device is already rooted/compromised, the attacker could intercept the passphrase during entry.

For the highest-value accounts (primary email, banking, crypto exchange), consider a hardware security key (FIDO2/WebAuthn) instead of or in addition to TOTP backup codes.