We can’t read your logins. Here is how.
ClientKeeps is zero-knowledge: your logins are encrypted in your browser with keys only your team holds. Our servers store and sync the encrypted version; they can’t open it, and neither can anyone who breaks into them.
What our servers can and can’t see
Our servers can’t see
- Your master password, or any key that can decrypt your logins.
- Usernames, passwords, URLs, 2FA keys, notes, SSH keys and attached files.
- What a client sends you through a request link: it is sealed to your team in their browser.
Our servers can see
- Your clients, websites, resellers and the names of logins (so lists and search work).
- Who opened which login, and when (the audit log).
- Whether a password is weak, reused or breached, but never the password.
Encrypted in your browser
Every login is encrypted on your device with XChaCha20-Poly1305 before it is saved. Each login has its own key; each client’s keys are shared only with the people and teams who may open them.
Your master password goes through Argon2id (256 MB of memory, so guessing is slow) in your browser. It never leaves your device; we store only a hash of a separate sign-in key derived from it.
Keys are shared between members with X25519 sealed boxes, and each member’s key is signed (Ed25519) by an admin who checked its security code with them. All of it uses the audited libsodium library; nothing is home-made.
Signing in
Signing in on a new computer, or a sign-in that looks unusual (another network, several wrong passwords), needs a second step: a code we email you, a code from your authenticator app, or your passkey (fingerprint, face or security key). An admin can require the app or a passkey for the whole workspace. Sign-in can also require your company’s Google account.
The vault locks when the tab is closed or reloaded, unless you chose to trust the computer: then it stays unlocked there for up to 14 days, until you lock it or sign out. An admin can turn that off, or make the vault lock itself after a period without use. Keys are wiped from memory when it locks.
Nobody can recover a forgotten master password, not even us. A reset gives the person a new key, and an admin on your team gives their access back after confirming it’s them.
Accountability
Every time someone opens a login, the server records it. The audit log is chained (each entry includes a hash of the one before) and anchored daily, so changes show.
When someone leaves, you see every login they could open and can rotate them from one list.
Each workspace is kept apart in the database itself (row-level security), not only in the code.
Backups and availability
Backups are encrypted before they leave the server, to keys kept offline. A backup can’t be read without your master password or your recovery sheet.
Restores are rehearsed with a drill that rebuilds a backup into a fresh database. Our status page shows incidents and maintenance.
Testing and reporting
An independent penetration test is scheduled before general availability. Until then, every change is checked by automated security tests.
Found a vulnerability? Email [email protected]. Please give us time to fix it before telling others; we reply within two working days and credit you if you wish.