Password vault and end-to-end encryption
What end-to-end encryption promises and what it doesn't, what the server sees, the master password and recovery code, disconnecting a device and revoking access.
What we promise
When end-to-end encryption is on in the vault, the key to your passwords exists only on your devices. The server — us as its operator, the hosting provider, anyone who steals a copy of the database — stores passwords, logins, notes, 2FA codes and hidden fields only in encrypted form and cannot read them. Entry titles, website addresses, tags, dates and fields you didn't make hidden stay readable — the list, search and reminders run on them. Bot and integration keys that you yourself marked as service entries are readable by the server: otherwise it couldn't hand them out without you.
"When it is on" is an essential part of that sentence. A new instance and a new Cloud account start in the regular mode: secrets are encrypted with the server's key. End-to-end encryption is turned on by the migration wizard in Settings → Vault.
The promise covers personal entries and data on the server — not "nobody, ever", but "the server can't". It doesn't protect an infected device (more on that below). And without the master password and recovery code the server can't restore access to personal entries either.
What the server sees
| Sees | Doesn't see |
|---|---|
| entry titles, website addresses, type, tags, favourites, archive, trash | password |
| names of all fields and values of non-hidden ones (text, link, date) | values of hidden fields |
| dates: created, edited, password changed, "time to change", last access | login |
| the access log: who opened, copied or viewed 2FA and when | notes |
| badges your client computed: "weak", "breached", "reused" — without the passwords themselves | 2FA seed and codes |
| service entries in full — it hands them to bots | |
| the encrypted keyring: which devices are connected, password parameters | master password and recovery code — they never leave the device |
"Reused" and "breached" badges are a hint: the server sees that several accounts share one password without knowing the password. Storing badges on the server can't be turned off yet.
Master password and recovery code
- The master password opens the vault. It is never sent to the server: the key is derived from it on the device. Use a long passphrase.
- The recovery code (25 characters) opens the vault if you forget the password. It is shown once — when you turn encryption on and when you revoke access; you can issue a new one in "Encryption keys", and the old one stops working.
- Lose both and your personal entries are gone for good. Neither we, nor the server admin, nor support can restore them: nobody has the key. Service entries remain.
- As a safety net, export the vault to a file (Vault → Export) protected by its own password.
Service entries
A service entry is a bot key, an integration token, a password that must be handed out without you (CLI, MCP, bots). The server encrypts and reads it. In the list it carries a server icon, and its card says the server reads it. Don't put personal passwords there.
"Disconnect device" and "Revoke access"
These are different actions — don't mix them up.
| What it does | When | |
|---|---|---|
| Disconnect device | removes its way in (Face ID, extension). The vault key stays the same | a phone was sold or handed over, and the vault on it was locked |
| Revoke access | a new key for the whole vault: entries are re-encrypted in the browser, the old key can't read anything; every other device reconnects; a new recovery code is issued | a phone was stolen unlocked, a malicious extension may have run in the browser, you suspect the key leaked |
Both are on the web: Vault → Encryption keys. Changing the master password does not change the key: if the password may have leaked together with a device, use "Revoke access".
Separately, Vault → Devices has "Unlink" — it revokes a browser extension's token: the extension stops reaching the vault, and the encryption key doesn't change.
What it doesn't protect against
- An infected device. A keylogger or malicious extension sees what you see. After that — "Revoke access".
- A web version tampered with by the server itself. The web client is loaded from the server, and a malicious server could serve code that steals the password. The iPhone app and the extension are installed separately and can't be swapped like that.
- A weak master password. Guessing is slowed down, not impossible.
- First sign-in on a new device. The app and the web show the keyring generation and date — compare them with another of your devices. The extension doesn't show this yet.
- An entry's address. The title and website address are readable and not signed by the key: a malicious server could attach someone else's site to a personal entry. So the extension fills a personal entry only on sites you confirmed yourself: on a new site it asks in its own window and shows where the entry was filled before. Confirmed sites are remembered by the browser, not the server. If your "Bank" entry suddenly wants an unfamiliar site, don't confirm.
Moving an existing vault
The wizard (Settings → Vault) shows the list, suggests what to keep as service entries, encrypts entries in the browser, verifies each one and only then switches the mode. Nothing changes before the switch; for 14 days after it you can roll back with the master password (the recovery code won't do for that).
During those 14 days the server keeps a pre-migration snapshot: logins and notes are in plain text in it, passwords under the server's key. The promise above fully applies once the snapshot is deleted — automatically when the term ends, or earlier with "Delete snapshot" in Settings → Vault (no rollback after that).