What the server can read, and what it cannot
Your vault is encrypted on your device with a key the server never receives. That sentence is on every password manager’s website, so this page does the part that is usually missing: it says exactly which values are derived where, which one is sent, what the server can still see, and where the model is weaker than the headline.
Everything below is checkable. Where a claim rests on a mechanism rather than a promise, the mechanism is named.
Claims on this page were last read out of the source on
Where each key comes from
Your master password is never transmitted, and neither is the key that decrypts your vault. Both are produced on your device, from the password and your email address, every time you sign in.
One derived value does go to the server, and it is the third step below. It is a one-way function of a one-way function of your password: enough to prove you know the password, useless for decrypting anything.
Master password + your email address as the saltArgon2idMaster key, 32 bytes
Memory-hard on purpose: the cost parameters are chosen so that guessing at scale is expensive even with the hash in hand. Runs in your browser, in the extension, or natively on your phone.
Master keyHKDF-SHA256, info "stretch"Stretch key
One derivation splits into the two independent values below, so neither can be computed from the other.
Stretch keySHA-256Master password hash
This is the only derived value that is sent. The server hashes it again with bcrypt before storing it, so what sits in the database is a bcrypt hash of a SHA-256 of an HKDF of an Argon2id. It verifies a sign-in and decrypts nothing.
Stretch keyHKDF-SHA256, info "vault"Vault key
Never sent, never logged, never escrowed. It exists to unwrap the key below and nothing else.
Vault keyAES-256-GCMYour X25519 private key
Each account has an X25519 key pair. The public half is stored in the clear; the private half is stored only as ciphertext the server cannot open. This indirection is why changing your master password does not require re-encrypting your vault.
Your X25519 private keygroup key, then folder keyThe items themselves
Your private key unwraps the key of each group you are in; a group key unwraps the key of each folder that group may read; a folder key decrypts the items inside it.
- Argon2id · 64 MiB of memory · 3 passes · 4 lanes · 32-byte output
- AES-256-GCM · a fresh random 96-bit nonce for every single encryption
- Breach lookup · 5 characters of a SHA-1 hash leave the device, and nothing else
The cost parameters are fetched from the server at sign-in because they have to match the ones your account was created with. Sending weaker ones would not quietly downgrade you — it would produce a different hash, and the sign-in would simply fail.
An item is sealed under the key of the folder it lives in
Each item is encrypted with AES-256-GCM under its folder’s key, with a fresh random nonce for every single encryption — a new one each time you save, never reused. What reaches the server is the ciphertext, the nonce, and the structural fields it needs to store the row.
Version history is the same ciphertext, kept per revision, so recovering last week’s value is a client-side decryption of an older blob rather than something the server does for you. Folder names are encrypted too: the server holds the tree, not the labels on it.
Folder access is cryptographic, not a permission flag
This is the part most worth checking, because it is where a lot of products keep a boolean. Giving a group access to a folder writes that group its own copy of the folder’s key, encrypted so that only the group’s members can open it. The access record and the key are the same row.
So revoking a group removes its copy of the key. There is no flag left set to false with a readable key sitting behind it, and no code path in which the server decides whether to hand over plaintext — it has no plaintext to hand over. The same construction is what makes the free plan single-person: with no groups, there is nobody to wrap a folder key for.
Revocation is forward-looking, as it is in every system of this shape. Removing a key copy stops future reads; it cannot unsee what somebody already decrypted. When a person leaves, rotate the credentials themselves, not just their access.
Your two-factor secrets are deliberately not in here
The vault has no field for a TOTP secret and will not be given one. This is a design position, not a gap in the roadmap, and it is worth stating plainly because storing both in one record is common.
A password and its second factor in the same store are not two factors. Whatever reaches that store reaches both at once, and the second factor has stopped being a second anything — which is the entire reason for having one. Keeping them apart is the feature.
The import tool holds the line where it would be easiest to cross: when a file you import carries authenticator seeds, they are lifted out before anything is encrypted, never uploaded, and handed back to you at the end as otpauth:// QR codes to scan into an authenticator app. A separate product is the honest answer here, and we ship one.
Breach monitoring that never sends a password
Saved passwords are checked against known breach corpora without the password, or its full hash, leaving your device. The client hashes the password locally with SHA-1, sends the first five hex characters of that hash, and matches the remainder against the response in memory.
Five characters is roughly one millionth of the hash space, shared with hundreds of thousands of unrelated passwords. The server learns a prefix, never which entry matched, and never whether anything matched at all. The lookup is proxied through our backend rather than made from your browser, which also keeps your IP address away from the third party.
The report of what was found is itself encrypted before it is stored, and bound to your account so that a blob lifted from one account fails to decrypt for another rather than opening in the wrong dashboard.
Losing the password, and the one way back
You can generate a recovery key. It is high-entropy, shown once, and the server never sees it: what the server stores is a second copy of your X25519 private key, wrapped under a key derived from the recovery key. Presenting the recovery key unwraps that copy and restores access.
If you have not set one up and you forget your master password, your data is gone, and we cannot help — not "will not", cannot. That is the cost of the rest of this page, and it is the right way round: a vendor who can recover your vault for you is a vendor who can read it.
Separation that is not cryptographic, but is still structural
Every row in the database carries a workspace id, and PostgreSQL row-level security rejects a query that does not scope to one — so cross-workspace data access is a database-level refusal rather than a filter some handler has to remember to add.
Sessions are short-lived access tokens with rotating refresh tokens in HTTP-only cookies. API keys are scoped and stored as SHA-256 hashes, so the key we hold cannot be used to make a request. None of this protects your plaintext — the encryption does that — but it is what stands between two customers, and between a stolen key and your workspace.
What we can see
A zero-knowledge page that lists only what is hidden is not credible, so here is the other column. The server necessarily knows a great deal about the shape of your vault, because it has to store, index and bill for it.
This list was worked out from the database schema rather than written from intention. If you find something we hold that is not here, that is a mistake in this page and we want to know.
Ciphertext only — we cannot read these
- The contents of every item: names, usernames, passwords, notes, card numbers, keys, every field
- Folder names
- Every earlier version of every item
- The contents behind a public share link — its key travels in the link, not in our database
- Your X25519 private key, which is stored wrapped under your vault key
- Your master password and your vault key, which are never sent at all
- Your two-factor secrets, which are not stored here in any form
In the clear — we can see all of these
- How many items you have, and what KIND each one is: login, secure note, card, document, Wi-Fi, API key, SSH key, database, server
- When each item was created and last changed, how many revisions it has, and when it is set to expire
- Which folder each item is in, the shape of your folder tree, and how many folders there are
- Which member created each item
- Every member’s email address and full name, their date of birth if they entered one, and their profile picture
- Your group names, in plain text, and who belongs to each group
- Your workspace name, its plan, its billing status, trial dates, and your payment-processor customer id
- The audit log: each action, the kind of resource it touched, the exact time, and the IP address it came from
- For each share link: that it exists, how long it lasts, whether it has a passphrase, whether it burns on first read, how many times it has been opened and when
- Your master password hash — enough to verify a sign-in, not enough to decrypt anything
- The five-character hash prefixes a breach check sends, and the addresses your sessions come from
None of that is your passwords. All of it is information about you, and metadata is not nothing.
Stated as bluntly as it deserves: somebody with access to our database could tell that you keep four payment cards, that a folder they cannot name gained an item at 02:14 on a Sunday, and which address you were at when it happened. They could not tell you what any of it says.
Where this is weaker than the headline
Four places. None of them is a defect we are about to fix, which is why they are written down rather than left for a reader to find.
On a phone, the key is stored at rest
"Never leaves the device" is a statement about the wire, not about memory. On the web and in the extension the vault key exists only in RAM for the session. On iOS and Android it is persisted in the operating system’s keychain, protected by the platform and released only after a biometric check or the device passcode.
That is what biometric unlock re-reads, and it is deliberately not cleared when the app locks — clearing it would make biometric unlock impossible, because nothing on that path can re-derive the key from a master password that is not kept anywhere. Signing out removes it.
The consequence, stated plainly: on a phone the security floor is the device credential, not your master password. Someone who can satisfy your phone’s unlock can open your vault. It is an accepted trade, pinned by a test so that changing it is a decision rather than a tidy-up.
On the web, we serve the code that does the encryption
A browser application is fetched fresh on each visit, so its integrity depends on us shipping honest code and on that delivery not being tampered with. No amount of client-side cryptography escapes that: the client is ours.
The packaged clients are in a better position on this specific risk. The extension is a versioned, signed package from the Chrome Web Store and the mobile apps are signed store builds — each is a fixed artefact you can inspect, rather than a fresh download you have to trust. If this is your threat model, prefer them.
There is no published third-party audit
The construction here is standard — Argon2id, HKDF, AES-256-GCM, X25519, all used in the ordinary way and with well-reviewed implementations — but nobody outside the team has published a review of this particular implementation, and we are not going to imply otherwise by talking around it.
What we offer instead is specificity: this page names the mechanism behind every claim, so you can check the behaviour yourself rather than take a certificate’s word for it. A certificate would be better. It does not exist yet.
Sharing is narrower than you may expect
There is no person-to-person sharing and no organisation-wide shared vault. The two mechanisms that exist are group access to a folder, inside a workspace, and a temporary public link to a single item.
A public link is still zero-knowledge — its key is in the link, so we cannot read what was shared — but it is a link, and anybody who has it can open it until it expires, burns, or is revoked. Treat it as a way to hand something over once, not as a way to give a colleague ongoing access.
Which plan gets which of this
The cryptography is not one of them. Key derivation, item encryption and the zero-knowledge model are identical on every plan, free included — there is no version of this product where paying more means your data is better encrypted.
- Client-side encryption, per-folder keys, version history, multi-factor sign-in and device trust: every plan, free included
- Breach monitoring on saved passwords: paid plans
- Auto-lock timeouts, set per surface for web, extension and mobile: every plan. The workspace-wide CEILING an admin can impose on all three: paid plans
- Single sign-on with OIDC or SAML, on a DNS-verified domain, with just-in-time provisioning, optional enforcement and an owner break-glass route: Premium
- Audit log: the window is both how far back you can read and how long events are kept, and it lengthens with the plan
- API access with scoped, hashed keys: Premium
- Row-level workspace isolation in the database: not a plan feature, it is how the database is built
How to check this yourself
Four things you can verify without our help. If any of them does not behave as described, this page is wrong and we would like to hear about it.
- Open your browser’s network inspector and save an item. The request body carries an encrypted blob and a nonce. There is no field containing what you typed.
- Change your master password and watch what is uploaded: your re-wrapped private key, and not your items. That is only possible because the items were never encrypted under the password in the first place.
- Unpack the browser extension from the Chrome Web Store and read the code that derives the key and encrypts the item. It is a published, versioned artefact, not something we hand you differently each time.
- Ask us for everything we hold about you. What we can produce is the ciphertext and the metadata listed above — that is genuinely the whole of it.
Questions people ask about the model
- Can U2 Secured read my passwords?
- No. Items are encrypted on your device with AES-256-GCM under a key derived from your master password with Argon2id and HKDF, and that key is never transmitted. The server stores ciphertext and a nonce. The one derived value it does receive is a hash used to verify your sign-in, which it re-hashes with bcrypt before storing.
- What can you see, if not the passwords?
- The structure and the timing. How many items you have and what type each one is, your folder tree’s shape, who created what and when, your group names, your members’ names and email addresses, the audit log including the IP addresses actions came from, and your billing data. Folder names, item contents and version history are ciphertext. The full list is on this page.
- What happens if your servers are breached?
- Whoever took the data would hold ciphertext they have no key for, plus the metadata listed above, plus bcrypt hashes of already-derived password values. They could see the shape of your vault. They could not read it, and there is no key of ours anywhere that would change that — the keys are on your devices.
- Why are my two-factor codes not stored in the vault?
- Because a password and its second factor in one store are not two factors: whatever opens that store opens both. The vault has no field for a TOTP secret, and the importer deliberately lifts any it finds out of the data and hands them back as otpauth:// QR codes instead of uploading them. The Authenticator is a separate product for the same reason.
- Is the mobile app as safe as the website?
- It is different rather than simply better or worse. The phone stores your vault key at rest in the OS keychain, released after biometrics or the device passcode, so the floor there is your device credential rather than your master password. In exchange, a store build is a fixed signed artefact rather than code re-delivered on every visit. Both facts are on this page in full.
- If I forget my master password, can you reset it?
- Only if you set up a recovery key beforehand, which we never see — it unwraps a second stored copy of your private key. Without one, we cannot recover your vault. A vendor who could would be a vendor who could read it.
- Do I get weaker encryption on the free plan?
- No. Key derivation, item encryption and the zero-knowledge model are identical on every plan. What paid plans add is organisational: more capacity, breach monitoring, a longer audit log, single sign-on and API access.
Read it, then try it
A free workspace needs no card and uses exactly the architecture described above. If something on this page does not match what you observe, tell us — that is a bug in the page or in the product, and both matter.