Privacy Policy

DRAFT - for review by qualified legal counsel before publication. This is not legal advice.

Last updated: 2026-06-27 (date to be confirmed at publication).

1. Who we are

Bitvaulter ("Bitvaulter", "we", "us", or "our") is a zero-knowledge, end-to-end-encrypted password and secrets manager available at bitvaulter.com. It serves both individuals and families and developers and teams. Bitvaulter is self-hostable today, and a hosted option is planned.

The legal entity responsible for Bitvaulter (the "data controller" for the purposes of applicable data protection law) is:

• [PLACEHOLDER: legal entity name]
• [PLACEHOLDER: registered postal address]
• Contact: support@bitvaulter.com
• Data Protection Officer / privacy representative (if appointed): [PLACEHOLDER: DPO name and contact]

This policy explains what data the Bitvaulter service collects, how it is protected, what we can and cannot see, and the rights you have over your information.

Note on self-hosting. If you run your own Bitvaulter instance, the operator of that instance (which may be you or your organization) is the data controller for the data stored on it, and this policy describes the design and behavior of the software rather than the practices of that operator. The sections below describe the data flows for a Bitvaulter-operated service.

2. The zero-knowledge principle (read this first)

Bitvaulter is built so that we never receive your master password, the keys derived from it, or any plaintext content of your vault. All encryption and decryption happen locally on your device.

In practice this means:

• Your master password never leaves your device. It is never transmitted to or stored by our servers.
• The cryptographic keys derived from your master password (your Master Key, your User Key, and each per-item key) are never transmitted to or stored by our servers in a usable form.
• The actual contents of your vault - logins, passwords, notes, card details, files, and other secrets - are encrypted on your device before they are sent to us. We store only the resulting ciphertext and a minimal amount of metadata needed to operate the service.

The most important consequence: there is no recovery. Because we never possess your master password or your keys, no one - including Bitvaulter, our staff, or our infrastructure providers - can decrypt your vault or recover it if you forget your master password. If you lose your master password and have no other access (such as an encrypted local backup export), your encrypted data cannot be restored to readable form by anyone. Please keep your master password safe.

A further consequence applies to legal requests: see Section 11, Lawful requests and disclosures. Even a valid, compelled data request can only yield ciphertext and minimal metadata - never your plaintext vault.

3. The data we collect

We collect only what is necessary to operate an encrypted vault and to authenticate you. The table below is the authoritative description of what is stored on the server.

3.1 Account and authentication data

• Email address. Used as your account identifier, for sign-in, for transactional messages (for example, verification), and to look up your per-account key-derivation salt before you authenticate (the "prelogin" step). Your email is lowercased and trimmed for this lookup.
• Key-derivation parameters (KDF params). The type of key-derivation function, its iteration count, and a per-account random salt are stored so your client can re-derive your keys. Today this is PBKDF2-HMAC-SHA256 with 600,000 iterations using that random salt (older accounts may use your lowercased, trimmed email as the salt for backward compatibility). (See Section 12, Our cryptography in brief.)
• Authentication verifier. What your device sends to sign in is not your master password. It is a "Master Password Hash" derived locally from your Master Key. Our authentication layer stores only a bcrypt hash of that value, so the value your device sends cannot itself be read back out of our store.

3.2 Encrypted key material

So that your vault works across your devices, we store the following wrapped (encrypted) keys. None of these can be unwrapped without your master password:

• Your protected (wrapped) User Key.
• Your RSA public key and your encrypted (wrapped) private key - used to share items with you securely.

3.3 Encrypted vault contents

• Encrypted item rows. For each vault item we store its encrypted data blob (data_enc), its encrypted item key (key_enc), a non-sensitive type indicator, and a favorite flag.
• Encrypted files / attachments. Files you attach are encrypted on your device and stored as encrypted objects in a private, owner-scoped storage bucket.

Every stored row and every stored file object is scoped, by database Row-Level Security, to the authenticated account that owns it, so one account cannot access another's data.

3.4 What we do NOT collect or store

We never receive, and we never store, any of the following:

• Your master password.
• Your Master Key, your User Key, or any item key in usable form.
• Any plaintext vault content - no plaintext passwords, notes, card data, secrets, file contents, URLs, or item names.

We also do not operate third-party analytics, advertising, or tracking on the service. See Section 9, Cookies and local storage.

4. How we use your data and our lawful bases

We process the limited data above for the following purposes. Where the EU/UK General Data Protection Regulation (GDPR) applies, the corresponding lawful basis is shown; the precise basis and any local-law specifics will be finalized for [PLACEHOLDER: governing law / jurisdiction].

Because of the zero-knowledge design, we cannot and do not process the contents of your vault for any purpose - we cannot read it.

5. The breach-check feature (Have I Been Pwned)

Bitvaulter can check whether a password appears in known data breaches. This uses the Have I Been Pwned (HIBP) k-anonymity range API, and it is designed so that your password and its full hash never leave your device:

• Your device computes the SHA-1 hash of the password locally.
• Only the first 5 hexadecimal characters of that hash are sent to the HIBP range API.
• HIBP returns a range of candidate hash suffixes; the comparison that determines whether your password was found happens on your device.

We do not send the password itself or its full hash, and HIBP cannot determine which password you checked from the 5-character prefix alone.

6. Sharing, collections, and organizations

If you share items with others (for example, through collections in an organization), sharing is also end-to-end encrypted:

• Items in a collection are re-wrapped under a collection key.
• The collection key is encrypted ("wrapped") to each member's public key, so only intended members' devices can unwrap it.
• When a member is removed, the affected collection keys undergo a forward-secure rotation, so a removed member's old key cannot decrypt data created after their removal.

For machine and service-account access, the token's authentication secret is separated from its decryption capability: our servers store a one-way hash of the token secret (PBKDF2-HMAC-SHA256 today; Argon2id planned) for authentication, while the decryption key is derived separately on the client. This lets the server verify a token without being able to decrypt with it.

Throughout, the server stores only ciphertext and wrapped keys for shared data - never plaintext.

7. Subprocessors (service providers who process data on our behalf)

We rely on a small number of infrastructure providers to deliver the service. Each receives only what it needs to perform its function, and - consistent with the zero-knowledge design - none of them receives your master password, your keys, or your plaintext vault.

We will keep a current list of subprocessors and provide notice of material changes as required by [PLACEHOLDER: governing law / jurisdiction].

8. International transfers

Your data may be processed in countries other than the one in which you live, depending on where our subprocessors operate. Where required, we will rely on appropriate safeguards for international transfers (for example, Standard Contractual Clauses or an equivalent recognized mechanism). The specific transfer locations and safeguards will be confirmed for [PLACEHOLDER: international transfer mechanism and locations].

Note that international transfer concerns are substantially mitigated by the zero-knowledge design: whatever jurisdiction your encrypted data passes through, it remains ciphertext that cannot be decrypted there.

9. Cookies and local storage

Bitvaulter uses cookies and local device storage only for functional purposes. We do not use third-party analytics, advertising, or tracking technologies.

Specifically, we use:

• A session mechanism so you can stay signed in during use.
• Local device settings stored on your device (for example, interface preferences and local security settings such as auto-lock).

We do not load third-party scripts on the web client; our Content-Security-Policy is configured to block them.

10. Data retention and deletion

We retain your data for as long as your account exists, and only as needed to provide the service or to meet legal obligations.

• Deleting an item removes its encrypted row from the database.
• Deleting your account cascades to your profile, your encrypted items, and your stored encrypted files.

Because of the zero-knowledge design, deletion removes data that is already only ciphertext to us. We may retain limited records where required by law; any such retention will be defined for [PLACEHOLDER: governing law / jurisdiction].

You can also keep your own copy of your data through the encrypted local backup export described in Section 13. That export is itself encrypted under a separate export password.

11. Lawful requests and disclosures

We may receive law-enforcement requests, court orders, or other legally compelled demands for data. We will assess each request for validity and respond as required by applicable law.

A critical limitation applies because of the zero-knowledge design: the only account data we hold is ciphertext and minimal metadata (such as your email and KDF parameters). We do not hold your master password, your keys, or any plaintext. Therefore, even a valid, lawful data request can only yield encrypted data and that minimal metadata - never the readable contents of your vault. We cannot decrypt your vault for anyone, because we lack the means to do so.

12. Our cryptography in brief

This section is provided for transparency. It describes how protection is implemented; it is not a warranty of any particular security outcome.

• Key derivation (KDF): PBKDF2-HMAC-SHA256, 600,000 iterations, with a per-account random salt (older accounts may use your lowercased/trimmed email as the salt), producing a 256-bit Master Key. KDF parameters are stored per account. Argon2id is planned as a negotiable future KDF.
• Key hierarchy: the Master Key is expanded (via HKDF) into a 512-bit stretched key (a 256-bit AES key plus a 256-bit MAC key). A random 512-bit User Key is wrapped under that stretched key. Each vault item has its own random item key, wrapped under the User Key.
• Symmetric encryption (EncString type 2): AES-256-CBC with HMAC-SHA256, using encrypt-then-MAC. The MAC covers the IV and ciphertext and is verified with a constant-time comparison before any decryption.
• Key sharing (EncString type 4): RSA-2048 OAEP (SHA-1), used to wrap keys to a recipient's public key. (OAEP-SHA1 is retained for wire compatibility with the Bitwarden model.)
• File / attachment encryption: a self-contained encrypted blob of IV (16 bytes) + ciphertext + MAC (32 bytes).
• Transport: HTTPS/TLS only, with HTTP Strict Transport Security (HSTS) and a strict Content-Security-Policy that loads no third-party scripts.
• Client protections: idle auto-lock, clipboard auto-clear, and an encrypted local backup export (protected by a separate export password).

Honest limitations and roadmap

We aim to be transparent about what is not yet done:

• The KDF is PBKDF2 today; Argon2id is planned.
• RSA-OAEP-SHA1 is retained for Bitwarden compatibility.
• A third-party security audit and penetration test are planned before general availability and have not yet been completed.

We describe these design features accurately and do not overstate them; no security measure can guarantee absolute security.

13. Your rights

Subject to applicable law, you have rights over your personal data. Depending on where you live - for example under the GDPR (EU/UK) or the CCPA/CPRA (California) - these may include:

• Access / "know": to be told what personal data we hold about you. Note that the substantive contents of your vault are ciphertext that we cannot read; we can provide the account-level data we hold (such as your email and KDF parameters) and your encrypted data.
• Deletion / "erasure": to have your account and associated data deleted. Deleting your account cascades to your profile, encrypted items, and stored files (see Section 10).
• Portability: to obtain a copy of your data in a portable form. You can use Bitvaulter's encrypted local backup export, which produces a copy of your vault encrypted under a separate export password that you control.
• Correction / rectification: to correct inaccurate account data such as your email.
• Objection / restriction: to object to or restrict certain processing, where applicable.
• Non-discrimination (CCPA/CPRA): we will not discriminate against you for exercising your privacy rights.
• "Do Not Sell or Share" (CCPA/CPRA): we do not sell or share your personal information, and we do not use it for cross-context behavioral advertising.

To exercise any of these rights, contact support@bitvaulter.com. We may need to verify your identity before acting on a request. You also have the right to lodge a complaint with a supervisory authority in [PLACEHOLDER: relevant supervisory authority / jurisdiction].

Because of the zero-knowledge design, some rights are necessarily shaped by what is technically possible: we can act on the data we actually hold, but we cannot decrypt, correct, or hand over the readable contents of your vault, because we have no access to them.

14. Children

Bitvaulter is not directed to children, and we do not knowingly collect personal data from children below the age of [PLACEHOLDER: minimum age, e.g. 13 / 16 per jurisdiction]. If you believe a child has provided us with personal data, please contact support@bitvaulter.com and we will take appropriate steps.

15. Changes to this policy

We may update this policy from time to time. When we make material changes, we will update the "Last updated" date above and, where appropriate or required, provide additional notice. Your continued use of Bitvaulter after an update takes effect constitutes acceptance of the revised policy, to the extent permitted by [PLACEHOLDER: governing law / jurisdiction].

16. Contact

If you have questions about this policy or our data practices:

• Contact: support@bitvaulter.com
• Postal: [PLACEHOLDER: registered postal address]
• Data controller: [PLACEHOLDER: legal entity name]
• Governing law: [PLACEHOLDER: governing law / jurisdiction]

DRAFT - for review by qualified legal counsel before publication. This is not legal advice.