How Passbox protects your data

• Your data is encrypted on your device before it leaves it. The server stores only encrypted data.
• Two secrets protect your account: your master password and your Secret Key.
• Signing in works without sending your master password.
• Sharing is sealed with post-quantum cryptography, and members are verified with security codes.
• Nobody at Passbox can read your vault, and nobody can reset your master password.
• All of Passbox is open source under the MIT License.

You don't have to take our word for any of this:

• The complete design is public and documented in the repository, next to the code.
• Every change is built and tested automatically, including a check of all Rust dependencies for known vulnerabilities.
• All of Passbox is open source under the MIT License, so anyone can read and build it.
• Vulnerabilities can be reported privately, see below.

The key to your vault is made from two things: your master password, which only you know, and your Secret Key, a long random code that is created on your first device. The Secret Key is never sent to us. It is printed in your Emergency Kit, and you enter it once on each new device, or move it with a device code.

Why two? If someone stole a copy of a server database, they could try billions of passwords per second against it. Without the Secret Key, that does not work, however simple your master password is.

Most services check your password by receiving it, or a scrambled version of it. Passbox uses a method called OPAQUE instead: your device proves that it knows the password without sending it.

So even our server, or someone who has taken it over, never learns your master password.

Every entry is encrypted on your device, including its title, username and website, not just the password. Only your devices can decrypt it.

Each entry is also sealed to its place: the server cannot move it into another vault, swap it with another entry or relabel an old version as a newer one without your apps noticing.

When you share a vault, your device seals its key for each member's public key. Those key pairs combine today's elliptic-curve cryptography with ML-KEM, a method designed to resist quantum computers (X-Wing). Data you share today stays private even if someone records it now and decrypts it later.

Public keys go into a key directory that can only grow, and every grant is signed by the person who gave it. Admins confirm new members by comparing a security code. A server that tries to slip in its own key is noticed, which is the attack researchers used against other password managers in 2026.

Removing a member replaces the vault keys. Details are in docs/architecture/sharing.md.

Nobody can reset your master password. Instead there are independent ways back to your account key: a recovery code in your Emergency Kit, recovery through your family or team (on by default, so admins can restore access), and emergency access for a trusted person after a waiting period that you can stop.

Each of them is sealed on your device to keys the server does not have. A recovery sets a new master password and a new Secret Key, signs out every device and sends you an email.

The threat model, including what an approving admin can see, is in docs/architecture/recovery.md.

On top of the two secrets, you can protect your account with an authenticator app, security keys or passkeys, and ten one-time recovery codes. Each code works once, and wrong attempts are limited.

Passbox is zero-knowledge: the server cannot read your entries or your keys. To do its job, it does store a few things:

• your email address and your public keys
• your encrypted entries with their size, IDs, version numbers and timestamps
• which organizations, groups and shared vaults you belong to, and your role
• your signed-in devices with their names and IP addresses
• your account's activity log: sign-ins, sign-outs, password and two-step changes, recoveries

It never receives your master password, your Secret Key or any key that could decrypt your data.

In the database: PostgreSQL holds only what is listed above, so your entries are ciphertext there, too. Row-level security is a second line of defense: the API connects with its own role that sees only the rows of the signed-in account and its organizations, while migrations and background jobs use separate roles. It limits the damage of a bug in the server; it does not replace the encryption.

All of Passbox is public under the MIT License: the server, every app and the encryption core. Anyone can read, check and build it.

All cryptography lives in one Rust library that every app uses. The browser extension, the desktop app and the phone apps therefore protect your data in exactly the same way. Source code on GitHub.

• Hosted service: runs in data centers in Germany.
• Self-hosted: on your own server, in your own network and under your own rules. Free, with every feature. See the self-hosting guide.
• Either way, the server stores only encrypted data.

Please don't open a public issue for security problems. Report them privately through GitHub Security Advisories, and include:

• a description of the problem and its impact
• steps to reproduce it, or a proof of concept
• the affected version or commit

We confirm every report within three working days and keep you informed until it is fixed. We are happy to credit you in the advisory. Findings where a malicious or compromised server can read, change, swap or roll back vault data are especially welcome.

For security experts: the key points of the design. The full specification is in docs/architecture/cryptography.md.

Key derivation

The Account Unlock Key (AUK) and the OPAQUE password input are derived from both secrets. The Secret Key has 128 random bits.

k_password  = Argon2id(master_password, salt, params)k_secret    = HKDF-SHA256(secret_key, salt = account_id)master      = k_password XOR k_secretAUK         = HKDF-SHA256(master, "passbox/v1/auk")auth_secret = HKDF-SHA256(master, "passbox/v1/opaque-password")

Clients enforce a minimum of 64 MiB of memory and 3 passes for Argon2id and reject weaker parameters, whatever a server sends. New accounts use 128 MiB, 3 passes and a parallelism of 4.

OPAQUE sign-in

• OPAQUE (RFC 9807) with ristretto255, 3DH and SHA-512, bound to passbox/v1/login.
• A stolen OPAQUE record is useless for guessing passwords without the Secret Key.
• Session tokens are random 256-bit values; the server stores only their SHA-256 hash.
• Unknown email addresses get a stable fake response, so sign-in does not reveal which accounts exist.
• Online guessing is rate limited. Devices that signed in before present a device token, so failed attempts from elsewhere cannot lock the owner out.

Key hierarchy

All symmetric keys are 256-bit XChaCha20-Poly1305 keys generated by the client. Each ciphertext is bound to its context through associated data:

AUK ──wraps──▶ account key ──wraps──▶ vault key (personal) ──encrypts──▶ vault metadata, items                    ├──wraps──▶ account key pairs (X-Wing, Ed25519)                    └──wraps──▶ own copies of shared vault keys (per key epoch)account X-Wing key ──opens──▶ sealed vault, group and organization keys

Key pairs, sharing and the key directory

• Every account has an X-Wing (X25519 + ML-KEM-768) encryption key pair and an Ed25519 signing key pair, created in the core and stored encrypted with the account key.
• Keys are sealed with X-Wing + HKDF-SHA256 + XChaCha20-Poly1305, bound to a purpose, a context and the recipient key.
• Public bundles are canonically encoded, self-signed and appended to a hash-chained, server-signed key log.
• Vault grants are signed by the granter; shared items use version-2 associated data with the key epoch.

Encryption envelope

All symmetric encryption uses XChaCha20-Poly1305 with a random 192-bit nonce. The header bytes are authenticated together with the associated data. Unknown versions or algorithms are rejected, which prevents downgrades.

version (1) | algorithm (1) | nonce (24) | ciphertext + tag (16)

We list what is not solved yet, so you can judge the design for yourself.

• A server can still withhold changes or replay an entire older state of an item. A signed revision chain per vault will close this.
• Vault metadata is not bound to a revision yet.
• The key directory is a hash chain; efficient proofs, gossip between clients and external witnesses come next. Until then, new contacts rely on trust on first use unless you compare security codes.
• The waiting period of emergency access is enforced by the server.
• Server secrets (OPAQUE server keys, prelogin key, two-factor key, key log signing key) are stored unencrypted in the database. They do not protect vault confidentiality.

The white paper is the documentation in the repository. It is updated together with the code.

• Cryptography
• Key pairs and sharing
• Recovery and emergency access
• Security policy