The security model
AES-256-GCM deep dive, zero-knowledge guarantees, full threat model, and an honest answer to: what happens if VaultPass is breached?
“Zero-knowledge” means VaultPass has zero knowledgeof your plaintext data. Your vault is encrypted before it leaves your browser. We receive, store, and transmit only ciphertext. While you are checking in, your key is never assembled on our servers. Because delivery to your heir is automated, we hold the encrypted heir and sentinel shards and combine them only when the dead man's switch fires — a database-only breach yields ciphertext, not a usable key.
Prove it yourself →256-bit symmetric cipher in Galois/Counter Mode. Provides confidentiality via CTR mode and integrity via a 128-bit authentication tag. A single bit flip in the ciphertext causes decryption to fail entirely — tampering is cryptographically detectable.
Each vault key is a fresh random 256-bit key from the Web Crypto CSPRNG — not derived from a password — then split via Shamir's Secret Sharing (2-of-3). Any single shard reveals zero bits of the key.
A fresh 96-bit random IV is generated for every encryption operation. Reusing an IV with the same key would be catastrophic for GCM — we generate a new one every time your vault is saved.
All random values (salt, IV) are generated using the browser's built-in crypto.getRandomValues() — a cryptographically secure pseudo-random number generator backed by the OS entropy pool.
An honest assessment of what can and cannot go wrong.
Attacker obtains encrypted blobs, salts, IVs, and heir emails.
Without your master password, the blobs are computationally unrecoverable. AES-256 has never been broken. Brute-forcing 256-bit keys is physically impossible with any conceivable hardware.
Employee can see the same data as a breach: encrypted blobs and metadata.
Zero-knowledge architecture means employees have no elevated access. The encryption key never reaches our servers. Trust in VaultPass employees is not a security requirement.
A weak or reused login password risks account takeover via Supabase auth.
Use a unique, long passphrase and enable 2FA. Note: your vault key is a random key, not derived from your password — so a cracked login password alone does not decrypt vault ciphertext without your separately-held owner shard.
Attacker receives the encrypted vault email intended for your heir.
The vault is encrypted — the email alone is useless without the password you shared with your heir out-of-band (not via email). Interception exposes only ciphertext.
Malware on your device could capture your password during entry.
Client-side encryption cannot protect against a compromised device. Use a secure, trusted device. Consider a hardware security key for your master password storage.
Network attacker could intercept traffic.
All traffic is TLS 1.3. Encryption happens before the data leaves your browser — even a successful TLS interception yields only ciphertext.
An attacker with database-only access would obtain: encrypted vault blobs, encrypted heir + sentinel shards, IVs, heir email addresses, and check-in timestamps.
The heir and sentinel shards are themselves encrypted at rest with secrets held outside the database, so database-only access yields ciphertext that cannot be reconstructed or decrypted — and the underlying AES-256 would need more energy to brute-force than the sun produces in its lifetime. Your crypto remains safe.