Security
Security is the product.
A password manager holds the keys to your whole life. Here is, in plain language, how 2Secret protects them, what it can’t do (yet), and how you can check our work.
Principles
Six promises the design keeps for you.
-
Only you can decrypt
Encryption and decryption happen on your device. Servers, hosting providers and we can’t read your data.
-
Two secrets, not one
Your master password and a Secret Key from your device. Stealing one isn’t enough.
-
Encrypt everything
Not just passwords: titles, URLs, usernames, notes and vault names are encrypted too.
-
Your data stays yours
The 2Secret project hosts no vaults. Keep yours on your device or on your own server.
-
Open to inspection
All code is open source under the MIT or Apache 2.0 licence, so anyone can verify what it does.
-
Honest about limits
We tell you plainly what isn’t protected and what isn’t done yet.
Two-Secret Key Derivation
Two secrets, so a stolen database is useless.
If a vault is protected by a master password alone, an attacker who steals the server’s data can try billions of guesses at their leisure, and weak or reused passwords eventually fall.
2Secret adds a second secret: the Secret Key, 130 random bits created on your device. Your keys are derived from the master password and the Secret Key together. The Secret Key never goes to the server, so a copy of the server’s database doesn’t contain what an attacker would need, however many guesses they make.
For the technically curious
- The master password is stretched with Argon2id using 64 MiB of memory and 3 passes.
- It is combined with the 130-bit Secret Key to derive your keys.
- Master passwords need at least 12 characters and a “good” strength rating.
- Apps refuse to derive keys, and servers refuse to store accounts, with Argon2id parameters below 19 MiB and 2 passes, so a hostile or outdated server can’t talk your app into weak key derivation.
- The server stores only an Argon2id hash of an authentication key, never anything that can decrypt your data.
Secret Key and Emergency Kit
Keep your Emergency Kit somewhere safe.
Your Secret Key looks like 2S-XXXXXX-XXXXX-XXXXX-XXXXX-XXXXXX. You don’t have to remember it: your devices keep it, and it’s printed on your Emergency Kit when you create your account.
You need the Secret Key, together with your master password, to sign in on a new device. Because nobody else can read your vault, nobody else can reset your master password or recover your Secret Key for you either.
- Print it, or save it somewhere offline, like a safe or with important papers
- Don’t keep it in the same place as your master password
- Never share it: nobody from 2Secret will ever ask for it
Encryption
Every item locked on your device, each vault with its own key.
Before anything leaves your device, every item is encrypted with XChaCha20-Poly1305 and a 256-bit key. Each vault has its own key, so sharing one vault never exposes another.
And it isn’t just the passwords. Titles, URLs, usernames, notes and vault names are encrypted too. LastPass, by contrast, left website addresses readable on its servers.
For the technically curious
- Authenticated encryption: XChaCha20-Poly1305 detects any change to the ciphertext.
- Bound to its place: every ciphertext carries associated data that ties it to its location, so a server can’t move an encrypted item to another vault, or swap one item for another, without decryption failing.
- Padding: data is padded to size classes, so the server doesn’t learn the exact size of your items.
Zero knowledge
What the server can and cannot see.
If you sync, your devices talk to a 2Secret server: one you run yourself, or one run by someone you trust. This is what that server, and whoever runs it, can and can’t see.
| Data | Visible to the server? | Why |
|---|---|---|
| Your master password | No | It never leaves your device. |
| Your Secret Key | No | Created on your device and never sent. |
| Passwords, notes, card numbers and other item contents | No | Encrypted with XChaCha20-Poly1305 before upload. |
| Titles, URLs, usernames and vault names | No | Encrypted as well. |
| The exact size of your items | No | Padded to size classes. |
| Your e-mail address and display name | Yes | Needed for signing in and sharing. |
| Your salt, Argon2id settings and public keys | Yes | Needed to set up new devices and to share vaults. None of it can decrypt anything. |
| A hash of your authentication key | Yes | An Argon2id hash: enough to check a sign-in, useless for decrypting. |
| Encrypted data (ciphertext) | Yes | That’s what it stores, without the keys to open it. |
| What you share at a link, and the vault keys for your emergency contacts | No | A link’s key is only in the link; the keys for emergency access are encrypted for your contacts’ public keys. |
| When share links expire, how often they can still be opened and whether they have a password; your emergency contacts, their waiting periods and requests | Yes | Needed to give out and delete links, and to keep to the waiting period. |
| Metadata: how many vaults and items you have, their size classes, when they changed, who shares a vault with whom and with which role, IP addresses | Partly | It needs this to sync and share, and like any server it sees traffic. See the limitations below. |
Running your own server means “the operator” is you, or the person you trust to host it.
Server
A server that knows as little as possible.
-
Ciphertext only
Encrypted data, an Argon2id hash of an authentication key and what it needs to sign you in and share. Never a key that decrypts anything.
-
Rate-limited sign-in
At most 10 failed sign-ins per account per 15 minutes.
-
No account probing
Unknown e-mail addresses get stable fake salts, and failed sign-ins take as long as real ones, so the server doesn’t reveal who has an account.
-
Hardened web vault
The web vault is served with a strict Content-Security-Policy: no inline scripts, no
eval, no framing.
Quantum-resistant sharing
Sharing that stays private, even in a quantum future.
Some attackers record encrypted traffic today, hoping to decrypt it once quantum computers are powerful enough: “harvest now, decrypt later”.
When you share a vault, 2Secret wraps the vault’s key for the other person with a hybrid of X25519 and ML-KEM-768, the post-quantum standard NIST published as FIPS 203. It’s the same approach Signal (PQXDH) and Apple (PQ3) use: an attacker would have to break both.
For the technically curious
- The vault key is wrapped with hybrid X25519 + ML-KEM-768 key encapsulation.
- The server only passes the wrapped key along.
- On the recipient’s next sync, the key is re-wrapped with their own 256-bit account key.
- Roles: viewer (read), editor (change items) and manager (also manage members).
- Removing someone gives the vault a new key: everything is re-encrypted, so what is added or changed afterwards is unreadable with the key they had. Managers can also replace a vault’s key themselves.
Fingerprints
Be sure who you share with.
Every account has a public key with a short fingerprint, such as 3F9A-77C1-0B2E-91D4. When you share a vault, 2Secret shows the other person’s fingerprint in the member list; they find their own in Settings. Compare them in person or over a call. If they match, nobody in between, not even a compromised server, has swapped in their own key.
Emergency access
Access for someone you trust, after a wait you choose.
Your device encrypts the key of every vault you own for each emergency contact, in the same quantum-resistant way as sharing, and keeps that up to date on every sync. The server holds these keys back and can’t open them. When a contact asks for access and you don’t deny it within the waiting period, the server makes them a viewer of those vaults.
For the technically curious
- Up to ten contacts per account, each with a waiting period of 1 to 90 days (1 to 30 in the apps). Compare their fingerprint, as when you share a vault.
- Denying after access was given, ending it or removing the contact takes them out of your vaults, and your device gives those vaults new keys.
- Vaults others shared with you are never included. Nobody gets your account, master password or Secret Key.
- The server keeps to the waiting period: a server that works with your contact could give access early. It can’t read your vaults on its own.
Browser extension
Autofill without the autofill risks.
Autofill is where password managers have been caught out: web pages and hidden frames that trigger fills or read data. The 2Secret extension is designed around those lessons.
-
Fills only on an explicit click
Never on page load, never in the background.
-
Checks again right before filling
The page and every frame are re-checked against the item’s website at the moment of filling.
-
Matches the real domain
Websites are matched on their registrable domain using the Public Suffix List, so look-alike subdomains don’t fool it.
-
No downgrade to http
A login saved for an
httpssite is never filled into anhttppage. -
Logins stay out of the page
Logins and one-time codes never pass through a content script. The small passkey script reads nothing from the page; it only forwards the passkey request.
-
You decide on passkeys
A website can only ask for a passkey. 2Secret opens its own window where you save or use one, or let the browser use another device instead.
Lessons from LastPass
What went wrong elsewhere, and how 2Secret handles it.
Attackers stole encrypted LastPass vault backups. The weaknesses that made those breaches so damaging shaped 2Secret’s design.
| What went wrong at LastPass | How 2Secret handles it |
|---|---|
| Stolen vault backups could be attacked offline; weak master passwords fell first. | The Secret Key adds 130 random bits to every account: the server database alone is useless for guessing passwords. |
| Website URLs were stored unencrypted, revealing which sites every user has. | Titles, URLs, usernames, notes and vault names are all encrypted; item sizes are padded. |
| Old accounts kept 1 to 5,000 PBKDF2 iterations for years. | Argon2id (64 MiB, 3 passes) from day one, with an enforced minimum on client and server. |
| Short master passwords (8 characters) were allowed. | At least 12 characters and a “good” strength rating. |
| Older vaults used AES-ECB/CBC without integrity protection. | Authenticated encryption (XChaCha20-Poly1305), with every ciphertext bound to its place. |
| Browser extension bugs let web pages and iframes trigger fills or read data. | Fill only on an explicit click, with the page and every frame re-checked against the item. Pages can only ask for a passkey, which opens 2Secret for you to decide. |
| Access to the vault storage by a compromised engineer exposed everything. | The server never holds a key that decrypts anything, and self-hosters keep their own infrastructure. |
The same comparison is in the security white paper, next to the rest of the design.
Honest limitations
What 2Secret doesn’t protect against, or doesn’t do yet.
No security is perfect, and we’d rather you hear the limits from us.
- No independent audit yet. The cryptography uses well-studied algorithms and the code is open for review, but no independent firm has audited 2Secret so far.
- The server operator sees metadata. It can’t read your vault, but it can see your e-mail address, when you sync, how many items you have and their size classes, which accounts share a vault, and the IP addresses that connect.
- The web vault is only as trustworthy as the server that serves it. A malicious or hacked server could send a modified web app. The desktop and mobile apps, the extension and the CLI don’t have this problem.
- A shared link can be copied. Whoever opens a share link may keep what they saw. A server that is hacked while a link is valid could serve a page that leaks the link’s key; links that expire soon and open once limit that.
- The server keeps the waiting period of emergency access. A server that works with your emergency contact could give them access early. It still can’t read your vaults on its own.
- A compromised device can see what you see. 2Secret doesn’t protect against malware running as you on an unlocked device, or against a compromised operating system or browser: they can read the screen, memory and keystrokes.
- Lose a secret, lose the vault. If you lose your master password or your Secret Key, nobody, not even the server owner, can recover your data. That’s the price of nobody else being able to read it.
- Your sign-in’s TLS may not be quantum-resistant. That depends on your operating system or browser and the proxy in front of the server. The data inside is end-to-end encrypted either way.
- Not (yet) included: biometric unlock on Linux, Android and in the browser (the master password is needed there); creating passkeys outside the browser extension, and using them on Android and in the desktop apps; a Safari extension; system autofill on Android.
The complete, current list of security limitations is in the white paper.
Check our work
Found something? Tell us first.
We welcome security research. Report vulnerabilities privately so we can fix them before anyone is put at risk.