Security Architecture

Privacy-first by design. This page explains exactly how it works, what we store, and - More importantly - What we cannot see, so you don't have to take our word for anything.

What We Can Never See

Everything sensitive is encrypted or generated on your device, before it touches the network. That is not a policy promise - It is how the code works:

  • Passwords you generate - No network request fires. Watch devtools while you generate.
  • Your master passphrase - It never leaves your device, not even hashed.
  • Your vault's contents - Logins, notes and cards are AES-256-GCM ciphertext before upload.
  • Your encryption key - Derived on your device, held only in your browser's memory.
  • Text you hash, encrypt or breach-check - Every tool runs client-side; the breach check uses k-anonymity.
Data being encrypted on a laptop before traveling to a server that stores only scrambled blocks
One passphrase splitting into two keys: the encryption key stays on the device, only the auth key travels to the server

One Passphrase, Two Keys

PBKDF2-SHA256 stretches your master passphrase into 512 bits over 600,000 iterations - Then the two halves lead completely separate lives:

  1. Your browser fetches your account's public salt and iteration count.
  2. The first 256 bits become the AES vault key - It never leaves your device.
  3. The last 256 bits become the auth key - The only thing sent, and we store just a salted hash of it.
  4. Ciphertext comes down; decryption happens in your browser's memory. Ten idle minutes re-lock automatically.

The same model used by Bitwarden and 1Password. Deep dive: zero-knowledge, explained.

What Our Database Actually Holds

A complete copy of our database would give an attacker no readable vault data. Per account we store:

  • Email and optional name - To identify your account.
  • A salted hash of the auth key - Login proof without any decryption capability.
  • Public KDF parameters - Salt and iteration count; not secrets, just re-derivation inputs.
  • Opaque encrypted blobs - Plus a type label and timestamps. Nothing about the contents.
  • Aggregate page counts - Which pages were visited, never what you did on them.

To read one vault, an attacker must brute-force that user's passphrase through 600,000 PBKDF2 rounds per guess - Hopeless against a strong passphrase.

A vault of opaque encrypted blocks that a magnifying glass cannot see into
A shield protects the server, but device-side risks like phishing and malware remain on the user's side

What This Does Not Protect Against

Honesty is part of security. Zero-knowledge protects your data from us and from anyone who breaches us. It cannot protect against everything:

  • A weak master passphrase - Stolen ciphertext can be brute-forced offline if the passphrase is guessable. Use 5+ random words from the passphrase generator.
  • Malware on your device - A keylogger sees your passphrase as you type it. No architecture survives a compromised endpoint.
  • Forgetting your passphrase - There is no reset, by design. Keep an encrypted backup and store the passphrase somewhere physically secure.

The Cryptographic Details

ComponentWhat we useWhy
Random generationcrypto.getRandomValues() with rejection samplingOS-seeded CSPRNG; rejection sampling removes modulo bias
Key derivationPBKDF2-SHA256, 600,000 iterations, 128-bit salt (older vaults upgrade automatically at next unlock)OWASP-recommended work factor; unique salt per account
Vault encryptionAES-256-GCM, fresh 96-bit IV per itemAuthenticated encryption - Tampered ciphertext fails loudly
Auth verifierSalted hash of a derived auth key (never the passphrase)Login proof without a decryption capability
TransportTLS, HSTS, same-origin API guardsStandard layers on top, not instead, of client-side crypto
Breach checkHave I Been Pwned k-anonymity (5-char hash prefix)Your password never leaves the browser, even hashed

Security Questions, Answered Straight

Can PasswordGenerator.now employees see my saved passwords?
No. Vault items are encrypted with AES-256-GCM in your browser before upload, with a key derived from your master passphrase on your device. Our database holds only ciphertext. There is no admin tool, support process or database query that can decrypt it - The key never exists on our side.
What exactly do your servers store about my vault?
Per account: your email, optional name, a salted hash of an authentication key (not your passphrase), the public KDF salt and iteration count, and your encrypted item blobs. Per blob we also see its type label (login, note or card) and timestamps - Nothing about its contents.
What happens if your database is stolen?
The thief gets ciphertext. To read one vault they would have to brute-force that user's master passphrase through 600,000 rounds of PBKDF2 per guess, per account. A strong passphrase makes that computationally hopeless - Which is why we enforce a minimum strength when you create one.
Why is there no password reset for the vault?
Because a reset would require us to hold a key that can decrypt your data - And then a court order, a rogue employee or a hacker could use it too. No reset is the proof that no such key exists. Export an encrypted backup and keep your passphrase safe.
Is the generator really private if the site is online?
Yes - Generation uses your browser's crypto.getRandomValues() and fires no network request. You can verify it: open devtools, watch the Network tab, generate. The site even works offline once loaded, which would be impossible if generation needed our servers.

Found a vulnerability? See security.txt or contact us - Security reports are answered within 48 hours.