Reporting a vulnerability

Please do not open a public issue for undisclosed security vulnerabilities. We treat reports in good faith seriously.

Use the contact channels described in our Privacy Policy (section Contact) or the website operator for this deployment.

Include the affected surface (web app, extension, API, cryptography), a short description, and reproduction steps if possible. For the open-source repository, see also SECURITY.md at the project root.

Scope

Examples of in-scope topics:

Vault encryption, key derivation, or serialization in client code and shared libraries.
Account Abstraction identity, Smart Wallet derivation, delegations, or abuse of sync / vault-CID APIs.
Browser extension isolation, content scripts, or messaging boundaries.
Server-side handling of ciphertext, signatures, or metadata that could weaken user security.
Protocols and smart contracts governing asset ownership and recovery.

What to expect

We aim to acknowledge receipt within a few business days. We also run a public Vault Challenge with a growing reward pool — follow our public channels for the next launch.

Coordinated disclosure process

Every report follows the same lifecycle so that you always know where your submission stands and what happens next:

Intake. You send a description of the issue by email. Acknowledgment is sent within a few business days.
Triage. The report is reproduced and assessed for impact (which surfaces are affected, whether ciphertext or keys could ever be exposed client-side).
Remediation. A patch is developed. Critical issues are prioritized and shipped ahead of any scheduled release.
Release. Clients are updated across all platforms (extension, iOS, Android), and the fix is documented in the public changelog.
Publication. Once a fixed version is deployed, coordinated publication of your findings is welcome. With your consent, we credit reporters by name or handle.

We will never take legal action against good-faith research that respects this process, user privacy, and system availability (safe harbor).

Cryptographic standards

The password manager is built on a small set of modern, well-studied primitives, derived client-side only:

Vault encryption: XChaCha20-Poly1305 authenticated encryption with a random 192-bit nonce per operation, implemented on top of the audited @noble library family.
Key derivation: Argon2id (time cost 3, memory cost 64 MiB, parallelism 4) maps your credentials to encryption keys locally. The parameters are stored alongside exported backups so older archives stay verifiable.
Integrity: HMAC-SHA256 is used where keyed authentication complements AEAD sealing.
Identity: Smart Wallet addresses are derived with secp256k1 elliptic-curve cryptography (ECIES-style encryption where secrets travel to devices).
Fragmented recovery: an optional Shamir secret sharing scheme splits a recovery secret into independent fragments kept apart, so losing one device or location does not compromise or lock out the vault.
Passwordless login: WebAuthn passkeys with the PRF extension derive key material inside platform authenticators (Face ID, Touch ID, Windows Hello) instead of storing a reusable master password.

A deep-dive into each layer lives in our technical documentation, including how ciphertext blobs are addressed on decentralized storage without leaking metadata.

Defense in depth

Beyond the cryptographic core, several layers reduce the blast radius of potential bugs:

Clients render a strict Content-Security-Policy with per-request nonces; scripts must be explicitly allow-listed.
The browser extension separates privileged logic from content scripts, minimizing the surface reachable by web pages.
Servers receive ciphertext and wallet signatures — never plaintext credentials — so infrastructure compromise does not translate into vault compromise.
Security headers (HSTS, frame protection, referrer policy) are enforced on every response.
A phishing blocklist bundled into the build warns before autofilling on known-malicious domains; it never sends user data anywhere at runtime.

Out of scope

To focus effort where it protects users most, the following are generally considered outside the bounty scope:

Attacks requiring physical access to an unlocked device.
Social engineering of users or staff (phishing them into revealing their own recovery data).
Missing rate limiting without demonstrated resource or security impact.
Reports about outdated library versions without a working exploit path.
Automated scanner output without a concrete proof of concept.

Frequently asked questions

Can VaultKeepR employees read my passwords?: No. Encryption and decryption happen on your device with keys that never leave it in plaintext form. Sync relays handle sealed ciphertext only.
Do I need a master password?: You choose your authentication model: a WebAuthn passkey with PRF-derived keys, or your own passphrase hardened through Argon2id. Both paths keep key material local.
Is the code open source?: Yes — the core vault libraries are published and reproducible, which means claims about the cryptography can be checked independently rather than taken on trust.
Where should I send sensitive reports?: To the disclosure email listed above, not to public GitHub issues. If you cannot use email, use the contact channel referenced in the Privacy Policy.

Security