Browser Vault localStorage Encryption

Important: What This Covers

This blog post explains the optional browser vault feature - a convenience tool for saving API keys to your browser’s localStorage with password encryption.

This is NOT about how we store API keys server-side. When you purchase an API key, we hash the secret with bcrypt (13 rounds) before storing it in our database. The plaintext secret is cleared after your first view.

The browser vault is entirely optional and runs 100% in your browser. Let’s explore how it works.

Browser-Only Encryption

When you save an API key to your browser vault, everything happens client-side:

1. Device-Specific Salt Generation

• First time only: Generate random 32-byte salt via CryptoJS.lib.WordArray.random(32)
• Stored in localStorage as unsandbox_device_salt
• Unique to your device and browser

2. Vault ID Derivation

• You provide a password (minimum 8 characters)
• Concatenate: password + device_salt
• Hash it: SHA256(password + device_salt)
• Result becomes your Vault ID

3. Encryption & Storage

• API keys encrypted using AES-256 with your password
• Encrypted data stored in localStorage as unsandbox_vaults
• Vault ID used as lookup key

4. Decryption

• Re-derive Vault ID from password + device salt
• Lookup encrypted data using Vault ID
• Decrypt with your password
• Keys only exist unencrypted in memory

Device Isolation

The same password on different devices produces different Vault IDs:

• Device A: SHA256("mypassword" + "salt_abc123") → Vault ID: def456...
• Device B: SHA256("mypassword" + "salt_xyz789") → Vault ID: ghi012...

Even if someone steals your password, they can’t access your vault without your device’s localStorage.

Zero-Knowledge Architecture

The server never receives:

• Your vault password
• Your device salt
• Your Vault ID
• Your encrypted keys

Everything stays in your browser’s localStorage. We literally cannot access your vault contents even if we wanted to.

The Trade-Off

What You Get ✅

• Maximum privacy - we can’t access your keys
• No server breach risk - there’s nothing to breach
• Device-specific security

What You Give Up ❌

• No cross-device sync
• No password recovery
• localStorage dependency - clearing browser data = permanent data loss

What Happens When You Clear localStorage?

This is critical: Clearing localStorage is permanent, unrecoverable data loss.

When you clear your browser’s localStorage, you lose:

1. The device salt - can’t regenerate Vault IDs anymore
2. The encrypted vaults - all encrypted API keys deleted forever

It’s like burning both the safe and the combination lock. Even if you remember your password, you can’t recreate the same Vault ID without the original device salt.

Why This Is Actually a Feature

• Clean slate: Complete factory reset
• No orphaned data: Old vaults can’t be accessed or leaked
• Self-destructing: Data doesn’t persist if you don’t want it to
• No backdoors: Not even you can recover it

Ultimate privacy-first design.

Security Properties

Deterministic Per-Device

• Same password + same device = same Vault ID (always)
• You can always unlock your vault with the correct password

Different Per-Device

• Same password + different device = different Vault ID
• Vaults are isolated and can’t be transferred

Cryptographically Strong

• SHA-256 for Vault ID derivation (one-way hash)
• AES-256 for encryption (military-grade)
• CryptoJS library (well-tested, widely used)

Best Practices

🔐 Password Security

• Use a strong, unique password (12+ characters)
• No password recovery exists - choose wisely

💾 Backup Strategy

• Export your keys from the unlocked vault to save them elsewhere
• Save exported keys in a password manager or encrypted file
• Vault is for convenience, not primary storage
• No import feature exists - keys must be manually re-entered if vault is lost
• Treat clearing localStorage like formatting a hard drive

🧹 Browser Maintenance

• Be careful when clearing browser data
• “Clear recent history” is safer than “Clear all history”
• Export keys before switching browsers

Comparison: Server-Side vs. Client-Side Vaults

Feature	Server-Side	Client-Side (Ours)
Password recovery	✅ Yes	❌ No
Cross-device sync	✅ Yes	❌ No
Export vault	✅ Yes	✅ Yes (JSON)
Import vault	✅ Yes	❌ No (manual entry)
Server can access keys	⚠️ Technically yes	✅ Impossible
Survives localStorage clear	✅ Yes	❌ No
Requires account	✅ Yes	✅ No
Subject to subpoena	⚠️ Yes	✅ No
True zero-knowledge	❌ No	✅ Yes

We chose security and privacy over convenience. For cross-device sync, use a dedicated password manager like 1Password, Bitwarden, or KeePass.

FAQ

Q: Can I recover my vault if I forget my password? A: No. We don’t have your password, salt, or keys.

Q: Can I use the same vault on multiple devices? A: No. Each device has a unique salt.

Q: What happens if I clear my browser cache? A: Cache is usually safe, but clearing localStorage deletes your vault permanently.

Q: Can unsandbox.com access my saved keys? A: No. Everything is encrypted in your browser.

Q: Is this more secure than a password manager? A: Different trade-offs. Password managers offer backup and sync. We offer zero-knowledge privacy. Use both!

Q: Can I export my vault? A: Yes! You can export all keys from an unlocked vault as JSON. However, there’s no import feature - you must manually re-enter keys if you lose your vault.

Conclusion

The browser vault prioritizes privacy and security over convenience. Perfect for users who value:

• Zero-knowledge security
• Client-side encryption
• No server-side storage
• Maximum privacy

Your keys, your device, your password. Nobody else—not even us—can access them.

That’s the way it should be. 🔐