Master password
Chosen by you at setup. Never transmitted. Used only as input to PBKDF2 on your device.
01 · CLIENT
master password →
PBKDF2
salted with user id; ≥100k iterations
02 · CLIENT
derived key →
Unwrap vault key
AES-256 unwrap, in memory only
03 · CLIENT
decrypt secret →
AES-256-GCM
authenticated, in the browser
04 · SERVER
at rest →
Ciphertext only
we can't read it
THE PIECES
What's actually in your account.
Derived key
Output of PBKDF2(master_password, salt=user_id). Held in memory while the app is unlocked. Discarded on lock.
Vault key
Random 256-bit key generated when the vault is created. Wrapped (AES) with your derived key. Decrypted on-device when you open the vault.
Invitation key
One-time key generated when you invite a member to a vault. Used to hand the vault key to them — replaced by their own wrapping on first unlock.
Recovery key
Generated at master-password setup, shown once, stored only by you. Encrypts a backup copy of your derived key so you can reset your master password without us.
Ciphertext payload
The actual secret value (login, password, card, note) AES-encrypted with the vault key. This is what the server stores.
THREAT MODEL
What this protects against.
| Threat | What an attacker gets |
|---|---|
| Server breach (database dump) | Encrypted blobs, hashed metadata. No plaintext secrets, no master passwords, no derived keys. |
| Server breach (compromised admin) | Same as above. We have no admin-level decrypt mode — there is no key on our side to compromise. |
| Network MITM | TLS-encrypted ciphertext in transit. Even with TLS termination, the payload is already encrypted with your vault key. |
| Phishing of master password | This is the user's risk to manage. We mitigate via session-bound prompts and master-password-never-stored in browser fields. |
| Stolen device, locked | Vault state is wiped from memory on lock. The on-disk cache is encrypted with the derived key, which is no longer held. |
| Stolen device, unlocked | Attacker can read currently-loaded vaults. Re-lock and revoke the device session from the Users page. |
Zero-knowledge password manager with shared vault
LitePassword combines a zero-knowledge architecture (master password never leaves your device, AES-256 + PBKDF2 derivation) with shared vaults that gate access by role. Each shared vault has its own random encryption key, wrapped with each member's master-derived key — plaintext never sits on our servers.
See the team sharing model →Password manager with role-based access for small teams
Three roles — Admin, Manager, View only — plus per-vault user permissions on top. No matrix to wire, no group hierarchy to maintain. Sized for teams of 12 or fewer.
Pick the use case that fits →Password manager with admin, manager, viewer roles
The three roles in LitePassword are explicit: Admin manages members and billing, Manager creates and edits vaults, View only reads what they're granted. Per-vault access sits on top — finer-grained than the account role.
Private and shared vault model
Every user gets a private vault auto-created on first sign-in — only they can ever unlock it, even if you're the workspace admin. Shared vaults sit next to it, gated by role and per-user vault access.
Password manager with no master password reset
By design — there is no vendor-initiated master password reset and no admin override. The recovery key generated on your device at setup is the only path. We never see it. If you lose both, your data is unrecoverable — that's the trade for end-to-end zero-knowledge encryption.
Password manager with recovery key setup
When you set up your master password, LitePassword generates a one-time recovery key on your device and shows it to you once. Save it somewhere physical (sealed envelope, fireproof safe). It's the only way to reset your master password later.
Password manager with custom field secrets
Five secret types ship with sensible default fields: Login (username, password, website, notes), Password, Credit Card, Secure Note, and Custom — where you define your own field names and values for anything outside the standard four.
Password manager with encrypted secure notes for teams
Use Secure Notes for recovery codes, MFA backup seeds, runbooks, or any sensitive text content. Encrypted with the same per-vault AES-256 key as logins and passwords, gated by the same role + per-vault access.
Password manager with field-level reveal
Every sensitive field stays masked by default. Click reveal to show one specific field; click copy to copy without revealing. Password fields show a live 5-tier strength meter when revealed.
Lightweight password manager without SSO requirement
LitePassword does not require — or offer — SSO. Sign in with email + password, or with a 6-digit email magic-code. The "no SSO" is deliberate: it keeps the recovery model strict (no enterprise IdP path that could weaken zero-knowledge) and keeps the product sized for under-12 person teams.
Start your free account →SECURITY FAQ
Common security questions, answered.
What does zero-knowledge mean for a password manager?
Zero-knowledge means the service provider has no way to read your stored data. With LitePassword, your master password derives a 256-bit key on your device using PBKDF2. That key — never sent to us — unwraps your per-vault keys and decrypts secrets in your browser. Our servers see only ciphertext.
How do I choose a password manager with strong encryption and zero-knowledge security?
Look for: (1) AES-256 or equivalent symmetric encryption applied client-side, (2) a key derivation function such as PBKDF2 or Argon2 with a high iteration count, (3) explicit documentation that the master password is never transmitted, (4) end-to-end encryption for shared vaults using per-recipient key wrapping, and (5) a self-issued recovery key the vendor cannot regenerate. LitePassword meets all five.
What is password-based encryption?
Password-based encryption derives a cryptographic key from a human-memorable password instead of generating one randomly. The function (PBKDF2, scrypt, or Argon2) stretches the password with many iterations and a per-user salt so brute-force attacks become impractical. The derived key is then used with a symmetric cipher like AES-256 to encrypt and decrypt data on the device.
How does LitePassword handle shared vault encryption?
Each shared vault has its own random encryption key. When you invite someone, your client decrypts the vault key locally, generates a one-time invitation key, and wraps the vault key with that invitation key. On the invited member's first unlock, their client unwraps the vault key and re-wraps it with their own master-derived key. The server only ever stores wrapped keys.
What happens if your servers are breached?
Attackers get a database of encrypted blobs. They cannot decrypt them without each user's master password, which is never transmitted. Recovery keys, master passwords, and master-derived keys exist only on user devices. The blast radius is therefore limited to metadata (account names, timestamps), not secret contents.
Why can't LitePassword reset my master password?
Because we don't have it, by design. The master password derives the encryption key on your device — we never see it. If we could reset it, we could also decrypt your vaults, which would defeat zero-knowledge encryption. Recovery is gated by the one-time recovery key issued at master-password setup.
Is AES-256 still considered secure?
Yes. AES-256 with a 256-bit key is a NIST-approved symmetric cipher with no known practical attacks. It is used by governments, banks, and major cloud providers. The security of an AES-256 password manager depends on the strength of the key — which in our case comes from PBKDF2 stretching a user-chosen master password salted with the user ID.
Try a password manager
that actually means it.
Create your account in under a minute. Pick a master password. We'll generate your recovery key for you.