himanshur.dev

Overview

Bitwarden (and its self-hosted counterpart, Vaultwarden) is built on a zero-knowledge security model. This means the server never has access to your plaintext passwords or master password — all encryption and decryption happens entirely on the client side (your browser, app, or extension).

Even with full access to the database, an attacker (or the server operator) cannot read your vault data without your master password.

Core Principles

Principle	Description
Client-side encryption	All vault data is encrypted before leaving your device
No master password transmission	Your master password never leaves your device
Zero server trust	The server stores only ciphertext it cannot decrypt
End-to-end encryption	Only you (and those you explicitly share with) can decrypt your data

Key Derivation Chain

The entire security model is built on deriving cryptographic keys from your master password:

Master Password + Email (salt)
          │
          ▼
  ┌──────────────────┐
  │  Key Derivation  │   PBKDF2-SHA256 (600,000 iterations, cloud)
  │    Function      │   or Argon2id (self-hosted / newer clients)
  └──────────────────┘
          │
          ▼
      Master Key  (256-bit, never leaves device, never stored)
          │
          ├──────────────────────────────────────┐
          ▼                                      ▼
  ┌──────────────────┐                 ┌──────────────────────┐
  │  HKDF Expand     │                 │  Hash for Auth Only  │
  │  (stretched key) │                 │  PBKDF2 (1 iter)     │
  └──────────────────┘                 └──────────────────────┘
          │                                      │
          ▼                                      ▼
  Encrypts Symmetric Key              Sent to server for login
  (AES-256-CBC + HMAC-SHA256)         verification only
          │
          ▼
  ┌──────────────────┐
  │  Symmetric Key   │  (randomly generated per account)
  │  (AES-256)       │
  └──────────────────┘
          │
          ▼
  Encrypts all vault items
  (passwords, usernames, notes, URIs, etc.)

What Is Stored on the Server

The server (Vaultwarden / Bitwarden) stores only encrypted blobs:

`users` table

Field	Content	Can server decrypt?
`password_hash`	Argon2/PBKDF2 hash of master password hash	❌ No — one-way hash
`key`	Protected Symmetric Key (encrypted with Master Key)	❌ No — needs Master Key
`private_key`	RSA-2048 private key (encrypted with Symmetric Key)	❌ No — needs Symmetric Key
`public_key`	RSA-2048 public key	✅ Yes — intentionally public

`ciphers` table (vault items)

Field	Content	Can server decrypt?
`data`	Encrypted JSON blob of login/note/card data	❌ No
`name`	Encrypted item name	❌ No
`fields`	Encrypted custom fields	❌ No

Encrypted value format

Every encrypted string follows this format:

2.BASE64_CIPHERTEXT|BASE64_IV|BASE64_MAC

2. — Encryption type identifier (AES-256-CBC + HMAC-SHA256)
BASE64_CIPHERTEXT — The actual encrypted data
BASE64_IV — Initialization Vector (random, unique per encryption)
BASE64_MAC — HMAC-SHA256 for integrity verification (prevents tampering)

Authentication vs. Decryption

These are two separate operations — a critical distinction:

LOGIN FLOW                          DECRYPTION FLOW
───────────────────────────────     ───────────────────────────────
1. User enters master password      1. Master Key derived locally
2. Hash is derived (PBKDF2)         2. Protected Symmetric Key fetched
3. Hash sent to server              3. Symmetric Key decrypted locally
4. Server verifies hash             4. Vault items decrypted locally
5. Server returns encrypted vault   5. Plaintext shown in UI

The server verifies identity but never participates in decryption.

Organization / Sharing Encryption

When you share items with an organization, asymmetric encryption (RSA) is used:

Organization Symmetric Key
          │
          ▼
Encrypted with each member's RSA Public Key
          │
          ▼
Stored in DB per member
          │
          ▼
Each member decrypts with their own RSA Private Key
(which itself is encrypted with their Symmetric Key)

This allows secure sharing without the server ever seeing the shared data.

What This Means in Practice

✅ What Bitwarden/Vaultwarden CAN do

Verify your identity at login (via password hash)
Store and sync your encrypted vault
Enforce access controls (2FA, IP restrictions, etc.)
Provide encrypted data to authorized clients

❌ What Bitwarden/Vaultwarden CANNOT do

Read your passwords or notes
Decrypt your vault (even with DB access)
Recover your master password
See what websites you've saved credentials for

Attack Scenarios

Scenario	Risk	Why
Server DB compromised	🟡 Low	Attacker gets only ciphertext; needs master password to decrypt
Server operator is malicious	🟡 Low	Same as above — zero-knowledge holds
Weak master password	🔴 High	Offline brute-force attack against the key derivation hash is feasible
Master password leaked	🔴 High	Full vault decryptable
Client device compromised	🔴 High	Attacker can read decrypted data in memory or storage
Man-in-the-middle (no HTTPS)	🔴 High	Encrypted vault can be intercepted (always use HTTPS/TLS)

Why Iteration Count Matters

The KDF iteration count (e.g., 600,000 for PBKDF2) directly controls how expensive brute-force is:

Time to crack = (Iterations × Hardware cost) / Guesses per second

Higher iterations = exponentially harder to brute-force, at the cost of slightly slower login. Argon2id (used in newer Bitwarden clients) is even more resistant as it also requires significant memory, making GPU-based attacks expensive.

Self-Hosted (Vaultwarden) Considerations

Running Vaultwarden gives you full control, but also full responsibility:

Enable HTTPS — without TLS, the encrypted vault is vulnerable to interception
Secure the host — if the server OS is compromised, an attacker could inject malicious client-side code
Backup /data/ — losing db.sqlite3 means losing the encrypted vault permanently
Keep Vaultwarden updated — client-side code is served by the server; a compromised server could serve malicious JS
Use strong master passwords — the zero-knowledge model only holds if the master password is not guessable

Summary

Bitwarden's zero-knowledge architecture ensures that the server is just a dumb encrypted storage backend. Your master password is the single point of trust, and it never leaves your device. This design means even a fully compromised Bitwarden/Vaultwarden server exposes nothing readable to an attacker — making the master password itself the only critical secret to protect.

Bitwarden Zero-Knowledge Architecture