Passlette Get started
← Back to About

Security details

A technical explanation of how Passlette's zero-knowledge encryption works.

How the encryption works

Account creation

When you create an account, your master password is run through Argon2id — a slow, memory-hard key derivation function — to produce two separate keys:

  • A server authentication token, which is sent to the server, hashed, and stored to verify your password at sign-in. The hash cannot be reversed.
  • An encryption key, which is used to encrypt your RSA private key. This key never leaves your browser.

Separately, your browser generates an RSA key pair. The RSA public key is stored on the server as-is. The RSA private key is encrypted with your encryption key and uploaded alongside it — the server stores only the encrypted form and cannot decrypt it.

Master password
Argon2id
Server auth token
Hashed and stored on server
Encryption key
never leaves your browser
Your browser also generates an RSA key pair:
RSA public key
stored on server
RSA private key
encrypted with encryption key
Encrypted RSA private key
stored on server
stored on server
sent to server, not stored
stays in browser

Signing in

When you sign in, your browser runs your password through Argon2id again to reproduce the same two keys. The server authentication token is sent to the server for verification. The encryption key is used to decrypt your stored RSA private key in your browser — the decrypted RSA private key never reaches the server. That RSA private key then decrypts the vault key for each group you belong to, which in turn decrypts your vault entries.

Master password
Argon2id
Server auth token
server verifies your password
Encryption key
decrypts (in browser)
Encrypted RSA private key
fetched from server
RSA private key
browser only
decrypts vault key
Decrypted vault entries

Groups and vault keys

Each group has a random 256-bit AES-GCM symmetric key — the vault key. When you create a group, this key is generated entirely in your browser and then encrypted with your RSA public key before being stored on the server.

When an admin invites someone to a group, the admin's browser decrypts the vault key (using their own private key) and re-encrypts it with the new member's public key. No plaintext vault key ever touches the server.

Vault key
encrypted with admin's public key
admin decrypts in browser
Vault key (plaintext)
temporarily in admin's browser only
re-encrypted for new member
Vault key
encrypted with new member's public key

Storing vault entries

Every credential you save — password, username, notes — is encrypted with the group's vault key using AES-256-GCM before being sent to the server. The server stores the ciphertext and a random IV. Decryption happens in your browser after you sign in and your RSA private key is decrypted.

Credential
password, username, notes
AES-256-GCM with vault key
Ciphertext + IV
stored on server; server sees only encrypted blob

What the server stores

  • Your email address
  • An Argon2id hash of your server authentication token — used to verify your password at sign-in; cannot be reversed to recover your password
  • Your RSA public key
  • Your RSA private key, encrypted with your encryption key
  • Vault entries as encrypted blobs — the server sees only ciphertext and a random IV per entry
  • An audit log of create, update, and delete events — timestamps and entry identifiers only; no credential content

What the server never sees

  • Your master password
  • Your Argon2id-derived encryption key
  • Your RSA private key in plaintext
  • The vault key for any group
  • Any credential content — passwords, usernames, or notes

Limitations and caveats

Zero-knowledge protects your data at rest on the server and in transit, but there are some things this model cannot prevent:

  • Compromised device. If an attacker can run code in your browser session, they could intercept your passwords before encryption. Keep your devices and browser extensions up to date.
  • Weak master password. Argon2id makes brute-force attacks slow, but a short or common password is still easier to crack. Use a strong, unique master password.
  • Server-delivered code. Because your browser fetches the application code from this server, a compromised server could theoretically serve malicious JavaScript. This is a limitation shared by all web-based password managers.
  • No master password recovery. Because the server never sees your encryption key, there is no mechanism to recover a forgotten master password. Your vault cannot be decrypted without it.

Reporting vulnerabilities

If you discover a security issue, please email security@passlette.com before publishing. We'll respond promptly, work with you to understand the issue, and credit you if you'd like. A machine-readable disclosure policy is available at /.well-known/security.txt.