Security & Vulnerability Disclosure

Email rakul0agn@gmail.com with "SECURITY" in the subject line. Please report privately first and give us a chance to fix the issue before disclosing it publicly.

A useful report includes:

• The app version (Settings, at the bottom) or the page URL
• Your device and Android version, if the issue is in the app
• Step-by-step instructions to reproduce it
• What an attacker gains, and what access they would need to start

Please do not include anyone's real credentials in a report. A dummy vault demonstrates the issue just as well.

• The OneVault Android app (package com.venzor.lockbox)
• The vault encryption and key handling: AES-256-GCM at rest, the Argon2id key-encryption-key, and the wrapped data key
• The encrypted backup format used for Google Drive and WebDAV
• The Android autofill service and its encrypted cache
• The browser extension
• This website, onevault.onebytez.com

These are either outside our control or are deliberate design decisions rather than defects:

• Attacks that require an already-rooted or already-compromised device
• Social engineering of users or of the developer
• Denial of service, rate-limiting, or traffic volume issues
• Physical access attacks against an unlocked device
• Vulnerabilities in third-party services we depend on (Google Play, Google Drive, RevenueCat, HaveIBeenPwned). Please report those to the provider.
• The plaintext CSV and 2FA exports. These are deliberately readable so your data stays portable, and they are gated behind a re-authentication prompt.
• Missing security headers or best-practice warnings on this static marketing site with no demonstrated impact.

• We acknowledge your report within 72 hours.
• We give you an assessment and a rough timeline within 7 days.
• We keep you updated while we work on a fix, and tell you when it ships.
• We credit you by name or handle in the release notes, unless you would rather stay anonymous.

OneVault is built by one person, so we cannot offer a paid bug bounty. What we can offer is a fast, honest response and public credit.

If you make a good-faith effort to follow this policy, we will not pursue legal action against you, and we will treat your research as authorised.

Good faith means: you only test against vaults and accounts you own, you do not access, modify, or delete anyone else's data, you do not degrade the service for other users, and you give us a reasonable window to fix the issue before disclosing it.

If a third party brings a claim against you for work that followed this policy, we will make it clear that your actions were authorised.

Some context that may save you time:

• Your vault is encrypted with AES-256-GCM. The 32-byte data key is never stored in plaintext. It is wrapped under a key derived from your master password using Argon2id (m=19 MiB, t=2, p=1), with the parameters recorded per blob so they can be raised later.
• We never receive your master password and never hold a copy of your data key. Backups are encrypted on your device before upload, so we cannot decrypt them.
• Google Drive backups live in the private appDataFolder, using only the drive.appdata OAuth scope.
• Breach checks use HaveIBeenPwned k-anonymity. Only the first 5 characters of a SHA-1 hash leave your device.

You do not have to take any of that on trust. The cryptography and the full vault/backup format are published at github.com/RakulAgn/onevault-crypto, including a step-by-step walkthrough for decrypting your own backup by hand and an explicit list of what the design does not protect against.

See the Privacy Policy for exactly what account data we do hold.