Trust Center · Whitepaper
Security whitepaper
A readable account of MGVault's cryptographic design: how your keys are derived, how sharing stays trustworthy, why you do not have to blindly trust the server, and where the design reaches its limits.
01
Summary
MGVault is a password manager that encrypts passwords, 2FA (TOTP) secrets and secure notes on your device. Encryption and decryption happen only in the client, that is, in the web vault and the browser extension. The server stores ciphertext, wrapped keys and the metadata the service needs to work.
The design has two goals: vault contents must stay unreadable even if the server is fully compromised, and in team sharing the server must not be able to slip a key in between members unnoticed. This paper explains how those goals are met and where they are not.
The byte-level format is specified in our internal documentation together with frozen test vectors; the web vault and the extension use the same crypto package. This paper is not an independent audit report: an independent third-party audit and penetration test are planned and have not been done yet.
02
Building blocks
| Purpose | Primitive | Parameters |
|---|---|---|
| Deriving keys from your master password | Argon2id | m = 64 MiB · t = 3 · p = 1 |
| Encrypting items and keys | XChaCha20-Poly1305 | 256-bit · 192-bit nonce |
| Sharing collection keys with members | X25519 sealed box | crypto_box_seal |
| Signing shared keys and key epochs | Ed25519 | RFC 8032 |
| Salts and key fingerprints | BLAKE2b | RFC 7693 |
All primitives come from libsodium (WebAssembly). The crypto package is cross-checked against test vectors from RFC 9106 (Argon2id), RFC 7693 (BLAKE2b), RFC 7748 (X25519), RFC 8032 (Ed25519) and XChaCha20-Poly1305, and against an independent reimplementation that does not use libsodium.
03
Key hierarchy
Everything starts from your master password, and no decryption key ever leaves your device in the clear.
- 1
Master password → Argon2id
The master password is run through Argon2id with a salt derived from your email address with BLAKE2b (by default 64 MiB of memory, 3 passes). The first half of the 64-byte output is the login key, the second half is the key-encryption key (KEK). Parameters are stored with the account; clients refuse values below a safe minimum and remember the strongest parameters seen for an email address, so the server cannot weaken key derivation.
- 2
The login key goes to the server, the KEK stays on the device
Only the login key is sent to the server, which hashes it again with Argon2id before storing it. Neither the KEK nor the master password can be recovered from that hash. The KEK never leaves your device.
- 3
Account key
At sign-up your device generates a random 256-bit account key and wraps it with the KEK using XChaCha20-Poly1305. Changing your master password only re-wraps this key; the vault does not have to be re-encrypted.
- 4
Identity keys: X25519 and Ed25519
Every account has an X25519 key pair, used to open keys that are shared with it, and an Ed25519 key pair, used to sign the keys it wraps for others. Private keys are encrypted with the account key; public keys are stored in the clear on the server. On unlock, the client checks that the public key it derives from the private key matches the one the server returned.
- 5
Vault (collection) keys
Every vault, personal or shared, uses its own random key. That key is wrapped separately for each member with a sealed box to the member's X25519 public key. Shared vault names are encrypted with this key too.
- 6
Items
Each item (login, 2FA secret, note) is encrypted with the vault key using XChaCha20-Poly1305. The associated data (AAD) binds the item ID, the vault and the version: an encrypted item cannot be moved to another item or vault, or replayed as an older version, without detection. Plaintext is padded to 64-byte blocks so the server does not learn the exact length of fields such as passwords.
- 7
Recovery code (Emergency Kit)
At sign-up a random 256-bit recovery code is generated (56 characters). Two keys are derived from it with BLAKE2b: one for verification on the server (which hashes it with Argon2id), the other to open a second wrap of the account key. The code is only shown to you, is never stored anywhere and is replaced whenever it is used.
05
Trusting keys: fingerprints and pinning
The public key directory comes from the server. That is why every device remembers for itself whose keys it trusts.
Pinning only through visible steps
Your device pins the keys of people in an organization only through steps you see: confirming an invitee after seeing their fingerprints, comparing a fingerprint and verifying it manually, or accepting the first wrap a device receives in an organization where it holds no keys yet, with a persistent notice. Nothing is pinned silently during verification.
Only pinned signers
A wrap is accepted only if its signer is pinned on this device and not revoked. Otherwise a warning is shown, the key is not used and the vault cannot be written to. A user invented by the server, or a key it swapped, is therefore not accepted.
Key changes are surfaced
If the key of someone you pinned changes, your device warns you and does not accept their new wraps until you approve the change.
Removed people are revoked
When a device sees that a member was removed from the organization, it revokes their pin; new epochs they sign afterwards are rejected.
Compare fingerprints out of band
Fingerprints are hexadecimal characters shown in 16 groups. Comparing them on a call or in person turns trust on first use into verified trust.
06
Threat model
We state plainly what we protect against and what we leave out of scope.
| Threat | Outcome and mitigation |
|---|---|
| Database or backup leak | The attacker only gets encrypted items, wrapped keys and a hash of the login key. The remaining risk is offline guessing of the master password, which Argon2id makes expensive. |
| Malicious or compromised server (stored data) | Cannot read vault contents. Cannot move items to another item or vault, or roll them back to an older version (AAD). |
| Server injects its own key into sharing | Wraps are signed and accepted only from pinned signers. |
| Server presents an old key as current | Clients track epochs monotonically and never write with an older epoch. |
| Server presents a fake member or fake recipient | Keys are only wrapped for pinned recipients; otherwise the operation stops and asks for a fingerprint comparison. |
| A removed manager colludes with the server | Their pin is revoked once the removal is observed; new epochs they sign are rejected. |
| Network attacker | TLS and HSTS, with end-to-end encryption underneath. |
| Stolen session | Short-lived access tokens, refresh tokens that change on every use, remote sign-out, auto-lock; master password and second factor for sensitive actions. |
Out of scope
- A device infected with malware or otherwise compromised: while the vault is unlocked, keys are in that device's memory.
- Someone who knows your master password and second factor, or who obtains your recovery code.
- An attacker who takes over the running server and serves modified code to the web vault (see the limitations below).
07
Known limitations
The honest limits of the design today:
- First contact relies on the server's directory. A sealed box on its own does not prove who wrapped it, which is why every wrap is signed with Ed25519. The public key directory, however, comes from the server: a device's first wrap in an organization can come from a signer chosen by the server. The notice shows the fingerprint but does not prevent this. There is no real key transparency yet; we recommend comparing fingerprints out of band.
- Pinning is per device. A new device knows nobody in the organization; you need to verify other members again. Revocation depends on the device observing the removal.
- Memory wiping is best effort. We wipe keys from memory after use as far as JavaScript allows, but the browser and the garbage collector may keep copies we cannot erase.
- A removed member knows what they saw. Key rotation protects new items. Passwords and 2FA secrets the departing person has already seen stay valid until you change them, which is why the rotation checklist exists.
- Whoever can read can copy. Someone allowed to read an item can copy it or write it down; encryption cannot prevent that. An organization policy can turn off copying or moving shared items into personal vaults, but nothing can stop a readable value from being copied by hand.
- Copy and autofill events cannot be verified. These audit events are reported by members' apps; the server cannot verify them and they are labeled as such in the log.
- The recovery code is full access. Anyone who knows your recovery code and email can open your vault, reset your master password and remove two-step login. When that happens all sessions end and a security email is sent. Keep the code offline in a safe place.
- The TOTP secret used for login is on the server. Because the server has to verify the second-step code at login, that secret is stored encrypted on the server: it is protected against database and backup leaks, but not against a compromise of the running server. 2FA secrets you store in your vault are not affected; they are end-to-end encrypted.
- The web vault loads its code from the server. Like every web app, the web vault downloads its code from our server each time it opens; someone who controls the server could in theory serve modified code. A strict CSP and the ban on third-party scripts narrow this surface. The browser extension ships its code with the installation and does not load remote code.
- Metadata is visible. The server sees your email address, organization names and memberships, and the number, approximate size and timestamps of items.
- Your master password matters. A short or reused master password can be guessed offline by someone who obtains the encrypted data.
08
Testing and verification
The crypto package is tested against standard test vectors and an independent reimplementation. If the format changes, the version number increases; old vectors stay frozen so existing data remains readable.
The design and code go through focused internal security reviews. Every finding is locked in by a regression test that fails before the fix. An independent third-party security audit and penetration test are planned; they have not been done yet.
Get started
Start your vault in under a minute
Free for personal use. Your keys are created on your device — right now, in your browser.