Security

Who can read your passwords? You.

Your master password never leaves your device, and the server stores only ciphertext it has no key for. Here is how that works, where a quantum computer changes anything, and — at the end — what Mabits does not protect you from.

Your master password never leaves your device

One key, derived where you type

Your master password goes through Argon2id — m=19 MiB, t=2, p=1 — on your device. Two values are derived from the result: one opens your vault key, and the other is what signs you in. The sign-in value decrypts nothing, and the server hashes it again before storing it.

A server cannot talk you into a weaker key

The key-derivation settings are bound into the key itself, so a server that lied about them would produce a key that simply fails to open your vault. Settings below a fixed floor are refused before any work is done.

Every item has a key of its own

Each item is sealed with AES-256-GCM under a random key made for it, and that key is sealed under your vault key. Sharing one item hands over one key and nothing else, and a leaked item key opens exactly one item.

Changing your master password re-seals one key, not your whole vault.

Post-quantum where a quantum computer actually matters

A quantum computer does not break AES-256, which is why your vault is sealed with it. What it breaks is public-key cryptography — the kind used to hand a key to somebody else — and ciphertext recorded today can be kept until it can.

Keys sealed to another account use both

Sharing an item, an organisation’s keys and an emergency contact’s access are sealed with X25519 and ML-KEM-768 together. Breaking the result needs both broken — the elliptic curve by a quantum computer, the lattice by a classical break nobody has found.

Public keys are signed twice

The keys you share with are published signed by Ed25519 and ML-DSA-65, both required, and pinned the first time you see them — so a key swapped out afterwards is caught. The first contact is the gap, and comparing fingerprints closes it.

Checked against NIST, on every build

ML-KEM and ML-DSA are written in this project rather than pulled from a library, and every build runs them against NIST’s own test vectors. Where a platform already provides an audited primitive — AES-GCM, X25519, Ed25519 — the platform’s is used instead.

What our server can and cannot see

Cannot see

Your master password, in any form that opens anything
Anything inside an item — its name, username, password, website or notes
Your folder names
What you search for, which happens on your device
Which sites you keep: icons are drawn from the item, never fetched from them
The exact size of an item — every one is padded before it is sealed

Can see

The email address you sign in with
How many items you have, and when they change
Roughly how large an attachment is, to within a megabyte — never its name or type
When you sign in, and which devices are signed in

A breached server has what the server has. That is why none of it is a key.

Signing in

A security key cannot be phished

Two-step login takes an authenticator app or a security key. Prefer the key: a convincing copy of this page can ask for an app’s six digits and relay them, but a security key signs for the site the browser is really on, and a copy is not it.

A stolen session goes stale in minutes

Access tokens last fifteen minutes and the token that renews them is replaced every time it is used, so a copy taken from somewhere goes stale — and using one ends the session and says so.

Any device can be signed out, now

Every session is listed, and revoking one takes effect on its next request — there is no cache for it to outlive. Recovery codes are stored only as hashes.

The browser holding your vault runs nothing third-party

The one thing no encryption repairs is hostile script in the page where you type your master password. So the page holding your vault runs under default-src 'none': no remote origin can load anything into it, and it may not execute a string as code.

Zero third-party code in the client

Not a crypto library, not an analytics SDK, not a font from somebody else’s server. A build rule enforces the short dependency allowlist, refuses install scripts outright, and fails if a package arrives without an integrity hash.

An extension you can rebuild

The browser extension builds reproducibly: anyone can rebuild it from the source and get exactly the files the release publishes, checked against one published hash.

What Mabits does not protect you from

A security page that claims everything is worthless. These are the ones that matter.

Malware on your device while your vault is unlocked. Something running as you can read what you can read. Mabits shortens the window — it locks itself and clears keys from memory — but no password manager closes it.
Anyone who can unlock your device, once you turn on biometric unlock. That is the trade the feature makes. It is off by default and set per device.
The browser extension can reach every site you visit. Autofill needs that. What reaches the extension is bounded, and nothing it reads leaves your device unless you chose to save it — but an extension that could be attacked could be attacked everywhere.
A breached server has your authenticator app’s seed. Checking a code means being able to make one. It does not open your vault, and a security key has no such weakness.
A forgotten master password. Without it, your recovery key, or an emergency contact you set up in advance, nobody can open your vault — us included. That is the point, and it is also final.
No independent audit, yet. The design is written down and the code is checked against standard vectors, but nobody outside this project has reviewed it, and there is no bug bounty.

Moving from somewhere else?

Your export is read on your device and never uploaded, and you see every item before anything is saved.

Open your vault How importing works