How MGVault protects your data

• Ongoing

  Internal security reviews

  We review the design and code in focused rounds. Findings are fixed and covered by tests before release.

• In place

  Cryptography tests

  Our crypto package is checked against standard test vectors (RFC 9106, RFC 7693, RFC 7748, XChaCha20-Poly1305) and against an independent reimplementation of our formats.

• Open

  Coordinated disclosure

  Report vulnerabilities by email. Contact details are also published in machine-readable form at /.well-known/security.txt.

An independent third-party security audit and a bug bounty program are planned.

Argon2id parameters are stored per account so they can be raised over time. Clients refuse parameters below a safe minimum, so a server can't weaken them.

1. 1

   Your master password is stretched with Argon2id

   Together with a salt derived from your email, it produces 64 bytes on your device. Half becomes a login key, half becomes your key-encryption key.

2. 2

   Only the login key is sent — and hashed again

   The server stores an Argon2id hash of the login key to check your login. The key-encryption key never leaves your device.

3. 3

   Your account key is wrapped

   A random 256-bit account key is encrypted with your key-encryption key. It protects your private keys for sharing and signing.

4. 4

   Each collection has its own key

   Personal and shared collections each use a random key, wrapped separately for every member with their X25519 public key.

5. 5

   Items are encrypted and bound to their place

   Items are encrypted with XChaCha20-Poly1305. The item ID, collection and version are authenticated, so an encrypted item can't be swapped or rolled back unnoticed. Padding hides the exact length of your data.

1. Exposed: encrypted data only

   The database and backups contain encrypted items, wrapped keys and an Argon2id hash of your login key. None of these reveal vault contents directly.

2. Not exposed: your keys

   Your master password, key-encryption key and account key never exist in plaintext on the server. There is no master key to steal.

3. Remaining risk: master password guessing

   An attacker could try to guess your master password offline against the stolen data. Argon2id (64 MiB, 3 passes) makes every guess expensive; a long, unique master password reduces this risk substantially.

4. Our obligation: timely notification

   In the event of a personal data breach we notify the Personal Data Protection Authority and affected users as soon as possible under Article 12 of KVKK, and tell you clearly what to do.

• Signed key epochs

  Every shared collection key is wrapped for a member with a sealed box and signed with Ed25519 by the person who shared it. Clients check the signature before opening anything.

• Fingerprint verification

  Admins confirm new members by their key fingerprints, which you can compare over a trusted channel. Unverified keys aren't used for sharing.

• Rotation when someone leaves

  Removing a member deletes their copies of the keys and moves the collection to a new key epoch. Clients refuse to write with an older key, so new items stay out of their reach.

• An honest rotation checklist

  Someone who leaves may remember what they saw. MGVault lists the passwords and 2FA codes they could access, so you can change them.

• Two-step login

  Add an authenticator app (TOTP) or passkeys (WebAuthn). The login TOTP secret is stored server-side, encrypted, because the server must check your code.

• Short-lived sessions

  Access tokens expire after 15 minutes. Refresh tokens rotate on every use, and reuse of an old token revokes the whole session.

• Devices you control

  See your active sessions and revoke any of them remotely. Security changes trigger an email notification.

• Rate limits

  Login, registration and recovery attempts are rate limited per IP address and per account, and responses don't reveal whether an account exists.

• Automatic locking

  Your vault locks after 15 minutes of inactivity, and keys are kept in memory only while it's unlocked.

• Four data centers in Türkiye

  Our servers and encrypted backups are distributed across four data centers in Türkiye: Datacasa, Mars Datacenter, Equinix and PenDC. The database and logs are kept in Türkiye and handled in line with KVKK.

• Row-level security

  PostgreSQL row-level security separates organizations as a second line of defense behind the application's own checks.

• Append-only audit log

  Audit events can be added but not edited by the application. Retention is 7 days on Free and 365 days on Team.

• Encrypted backups

  Nightly database backups are encrypted to a public key on the server and stored across our data centers in Türkiye, where the providers cannot read them. The private key needed to restore them is kept offline, and restores are tested.

• Strict browser policy

  A strict Content Security Policy with per-request nonces. No third-party scripts, fonts, trackers or analytics.

• Payments kept apart

  When paid plans launch, card payments will be handled by iyzico on a separate origin. Card data won't touch our servers.

• Network traffic

  In your browser’s developer tools you can see that saving an item sends only encrypted data to the server.

• Content Security Policy

  The CSP header on every response shows that pages run only nonce-bearing scripts from our own origin. There are no third-party scripts, fonts or trackers.

• Key fingerprints

  By comparing fingerprints with teammates by phone or in person, you confirm that shared keys reach the right people.

• Sessions and audit log

  You can review the active sessions on your account and your organization’s audit log, and end any session you do not recognize immediately.

• Lost master password and Emergency Kit. If you lose both, your data can't be recovered — by anyone, including us.
• Your master password matters. Argon2id slows guessing a lot, but a short or reused password can still be guessed offline by someone who obtains the encrypted data.
• First contact relies on trust. The first key you receive from a team member is trusted on first use unless you compare fingerprints out of band.
• Some audit events come from clients. Copy and autofill events are reported by members' apps and can't be verified by the server; they are labeled as such.
• Browser memory. We wipe keys from memory where JavaScript allows, but browsers may keep copies we can't erase.
• The web vault loads its code from our server. Like every web application, the web vault downloads its code from our server each time it opens, so someone who controlled 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.