Can Vault see my passwords?

No. Your vault is encrypted on your device with AES-256-GCM before it ever leaves. We operate a Supabase relay that carries only a revision number and a random device id so your other devices know to re-fetch — never vault content, entry names or key material.

Where is my data actually stored?

On your device, and if you enable sync, as ciphertext — either in your own Google Drive in the app-private appDataFolder area, or in our database if you sign in to a Vault account. Both hold only ciphertext, plus your vault key wrapped under your master password. We never receive that password, so we cannot open either.

What happens if I forget my master password?

Your data is unrecoverable by design. We hold no key that can decrypt your vault, and identity verification changes nothing. This is the trade-off that makes zero-knowledge encryption meaningful.

Yes. The free tier stores unlimited items with unlimited TOTP codes and passkeys on one synced device. Premium is $2.99/month or $24/year and adds unlimited devices, encrypted sharing, attachments and detailed password health.

Has Vault been security audited?

Not yet. No independent third-party security audit has been performed. The cryptographic design and its parameters are documented publicly rather than hidden.

Security

Last updated 25 July 2026

Vault is zero-knowledge by construction: your vault is encrypted on your device before it goes anywhere, and we operate no server that stores it. This page summarises the design and its limits. The full whitepaper lives in release/legal/security-whitepaper.md in the source repository.

Primitives and parameters

Vault contents: AES-256-GCM, 256-bit key, fresh 96-bit IV per operation, 128-bit authentication tag.
Key derivation, desktop and CLI: scrypt, N=2¹⁷ (~128 MB), r=8, p=1, 128-bit random per-vault salt.
Key derivation, browser extension, web app and mobile: PBKDF2-HMAC-SHA256, 600,000 iterations, 128-bit random salt.
Vault key: random 256-bit from the platform CSPRNG — never derived from your password — wrapped with AES-256-GCM under the derived key-encryption key.
Biometric unlock: WebAuthn PRF output stretched with scrypt, or an iOS Keychain item under Secure Enclave protection. An alternative wrapping of the same vault key, not a weaker key and not a bypass.
Sharing: ephemeral ECDH over NIST P-256, HKDF-SHA256, AES-256-GCM, a fresh ephemeral key pair per share. File-mode shares use PBKDF2-HMAC-SHA256 at 600,000 iterations.

Vault implements no custom cryptography. Every primitive is a standard, published algorithm composed from the platform's own implementation.

The two key-derivation tiers, stated honestly

The desktop app and CLI use scrypt, which is memory-hard. The browser extension, web app and mobile apps use PBKDF2 — because the W3C Web Crypto API exposes no memory-hard KDF at all, so the alternative would be shipping a hand-rolled scrypt or Argon2 in JavaScript or WASM with its own unaudited risks. 600,000 PBKDF2-HMAC-SHA256 iterations meet the OWASP 2024 floor, but PBKDF2 parallelises cheaply on GPUs where scrypt at a ~128 MB working set does not. Against an offline attacker holding your encrypted blob, the cost per guess is set by the weakest wrapping the vault carries — so for a vault also opened on mobile or in a browser, that is the PBKDF2 path. A long, high-entropy master password closes this gap; a weak one is protected materially less on mobile than on desktop. Unifying the tiers is the highest-value cryptographic improvement outstanding.

Sync and the relay

The encrypted vault goes from your device to your own Google Drive appDataFolder — never through our infrastructure. A Supabase Realtime channel carries a revision-changed ping on a topic scoped to your user identifier. The relay is treated as untrusted: a hostile relay can withhold, replay or forge pings, and the worst outcome is a device that syncs late or re-fetches unnecessarily. It cannot inject vault content, because content is fetched from Drive and authenticated by GCM.

What Vault does not protect against

A compromised operating system, malware or a keylogger on your device.
Someone with physical access to a device with your vault already unlocked.
Coerced disclosure of your master password. There is no duress mode and no hidden vault.
A phishing site into which you personally type a credential.
Metadata: revision timing, ciphertext size and change frequency are observable by the relay and by the storage provider. There is no padding and no cover traffic.
Clipboard exposure: copying a secret puts it in a system-wide buffer other applications can read. Vault clears it after a delay, which narrows but does not close the window.

Known limitations

No independent third-party security audit has been performed. Nothing on this page is an attested finding.
No formal verification, fuzzing campaign or side-channel analysis of Vault-specific code.
Changing your master password re-wraps the vault key rather than re-keying the vault, so ciphertext exfiltrated earlier stays decryptable by anyone who already had the old vault key.
P-256 sharing is not post-quantum secure.
The browser extension shares the browser's trust boundary; a compromised browser or a malicious extension with sufficient permissions can observe autofilled values.
Memory hygiene is best-effort. In garbage-collected runtimes, reliably zeroing secrets is not guaranteed.
Recovery is impossible by construction. No escrow, no operator-held recovery key, no reset.

Recommendations

Use a long, unique, high-entropy master passphrase. It is the single point of failure.
Keep an offline record of it somewhere physically secure, and export periodically.
Enable biometric unlock for convenience, but never forget the master password.
Set a short auto-lock interval, enable full-disk encryption and a device passcode.
Protect the Google account used for sync with phishing-resistant 2FA.
Prefer autofill over copy-paste: it avoids the clipboard and checks the origin.

Reporting a vulnerability

Email founder@dfacto.ai with reproduction steps. We aim to acknowledge within 3 business days and to give a remediation timeline within 10. Please give us a reasonable window to fix an issue before publishing. There is no bug bounty programme at this time, and we would rather say so than imply one.