Questions
What we can see, what happens when something goes wrong, and how to leave if you want to. Where the answer is not the one you would hope for, it says so.
No. Every item is encrypted on your device before it is sent, and the server stores only the result. It holds no key that opens it, and your master password never leaves your device in any form that opens anything. What the server does see — your email address, how many items you have, when you sign in — is listed in full.
No. There has been no third-party security audit, and there is no bug bounty yet. What exists instead is checking you can repeat: the cryptography runs against NIST’s own test vectors on every build, a build rule holds the browser to a short dependency allowlist with no crypto library or analytics in it, and the extension rebuilds from source to the exact files the release publishes. That is not a substitute for an audit, and it is not presented as one.
The attacker gets what the server has: encrypted items, and no key that opens them. Their only way in is to guess your master password, and every guess costs a full, deliberately slow key derivation. That makes a long random passphrase the thing that protects you — the generator makes one and shows you exactly how strong it is.
Yes. The server is one Node process storing encrypted blobs in a SQLite file, with no third-party runtime dependencies at all, and it holds no keys wherever it runs. Mabits is licensed under the AGPL-3.0.
Whenever a key is sealed to another account — sharing an item, an organisation, an emergency contact — Mabits uses X25519 and ML-KEM-768 together, so a recording made today cannot be opened by a quantum computer later. Your own vault is AES-256-GCM, which a quantum computer does not break. The long answer, including what is not post-quantum.
Nobody can reset it — not support, not us. That is the same fact as “we cannot see your passwords”, seen from the other side, and any company that can reset yours can read your vault. So the ways back in are ones you set up beforehand, and there are two.
A second key to your vault, shown to you once to print or write down. It is off until you turn it on, and the reason matters: anybody who finds that sheet can open your vault without your master password. Keep it where you keep a passport. Using it always shows a warning that cannot be switched off.
You choose a person who can ask for access to your vault. When they ask, a waiting period starts and you are told; you can refuse at any point during it. Only if the period ends with no refusal do they get in. It is for the day you cannot answer — and your vault key is sealed to their key, so our server never holds it.
Two-step login comes with recovery codes, and each works once. From any device that is still signed in you can sign the lost one out immediately, and rotate your vault key, so the key on the lost device opens nothing you save afterwards. What it already held, it held — which is why the master password matters more than the device.
Yes — Bitwarden, 1Password, LastPass, KeePass, and Chrome or any other browser’s export. The file is read on your device, you see every item before anything is saved, and a row that cannot be read is counted and reported. Where a manager offers more than one export, the richer one carries more across — a CSV brings only the columns Mabits recognises. Step-by-step for each one.
Yes. Export an encrypted file protected by a password you choose, or a plaintext file. A CSV opens in any other manager but only carries what CSV can: logins, with their notes and folders — not cards, identities, custom fields, passkeys or attachments. Mabits tells you that before it writes the file, and refuses to leave an attachment behind silently.
Not yet. The shared core that both apps will use has been written; the apps themselves have not. The web vault works in a phone’s browser and is checked at a 320-pixel-wide screen, but without an app there is no autofill in other apps.
Chrome and other Chromium-based browsers. There is no Firefox or Safari extension yet; the web vault works in both.
If you turn it on for a device. That device then keeps an encrypted copy of your vault, and opens it from that copy when our server cannot be reached — and says that is what it did. It is off by default because it leaves a copy of your encrypted vault on the device.
An authenticator app or a security key, with recovery codes for when you have neither. Prefer the security key: it cannot be phished, where an app’s six digits can be relayed by a convincing copy of the sign-in page.
The quickest way to know is to open a vault and import a copy of what you have. Nothing leaves your device unencrypted, and you can export it all again.