---
path: onboarding/security-review/encryption-review.mdx
title: Encryption review
sidebar_position: 5
slug: encryption-review
pagination_next: null
pagination_prev: null
description: >-
  Security review of Passwork's encryption architecture: verifying client-side
  encryption status, server key storage, algorithm parameters against NIST standards,
  Zero-Knowledge model, and backup encryption.
keywords:
  - Passwork
  - encryption
  - CSE
  - client-side encryption
  - Zero Knowledge
  - AES-256
  - RSA-2048
  - PBKDF2
  - server key
  - encryption audit
  - key hierarchy
---

This section documents the Passwork cryptographic architecture for compliance and audit purposes, and provides specific verification steps for on-premise deployments.

---

## 1. Encryption architecture overview

Passwork uses a layered encryption model. Understanding the architecture is required to correctly assess the security posture.

### Two-level protection

| Level | Algorithm | When active | What it protects |
|-------|-----------|-------------|------------------|
| **Server-side** | AES-256-CFB | Always | All data at rest in the database |
| **Client-side (CSE)** | AES-256-CBC | When CSE is enabled | Passwords, custom fields, TOTP secrets, attachments |

**With CSE disabled:** All data is encrypted by the server key. A database administrator with access to both the database and the server key can decrypt data. Server-side encryption protects against database file theft.

**With CSE enabled:** Critical fields (passwords, secrets) are encrypted on the user's device before being sent to the server. The server never holds unencrypted passwords. Server-side encryption adds a second layer on top.

### Key hierarchy (CSE enabled)

```
Master password (user-known, never transmitted)
    ↓ PBKDF2 (SHA-256, 300,000 iterations)
Master key (512 bits, in memory only)
    ↓ AES-256-CBC
Private RSA key (2048 bits, stored encrypted on server)
    ↓ RSA-OAEP (SHA-256)
Vault key (256 bits, stored RSA-encrypted per user on server)
    ↓ AES-256-CBC
Record key (256 bits, per record, stored encrypted on server)
    ↓ AES-256-CBC
Password field, custom fields, TOTP secret, attachment keys
```

Each vault and each record has a unique key. Compromising one key does not expose other records or vaults. The master key exists only in browser memory and is never persisted to the server.

Full key hierarchy specification: [Key hierarchy](https://passwork.pro/tech-guides/cryptography/key-hierarchy/)

---

## 2. Verify CSE status and justification

### 2.1 Determine current CSE status

Navigate to **Settings → System settings → Registration** (or check config.env):

| CSE Status | Indicator |
|------------|-----------|
| Enabled | Users are prompted for a master password on sign-in |
| Disabled | Users sign in without a master password prompt |

You can also check config.env (on-premise):

```bash
grep -i "client_side_encryption\|CSE\|ENCRYPTION" /var/www/init/config.env
```

### 2.2 Verify the decision is intentional and documented

The CSE decision should be documented in the organization's Information Security Policy or the Passwork deployment decision record.

| Deployment scenario | Expected CSE status |
|--------------------|---------------------|
| Cloud-hosted Passwork (passwork.pro) | Always **enabled** — cannot be disabled |
| On-premise, internet-accessible | **Enabled** strongly recommended |
| On-premise, air-gapped / private perimeter, strict physical security | **Disabled** acceptable with documented justification |

**Finding:** If CSE is disabled on an internet-accessible on-premise instance with no documented justification, this is a **high-severity finding**.

### 2.3 With CSE enabled — verify operational controls

- [ ] Master password complexity policy is configured (≥ 14 characters)
- [ ] Help desk has documented procedure for master password reset (with user impact: private vault data loss)
- [ ] Users are trained to store master passwords securely offline
- [ ] Vault administrators know how to approve vault access re-requests after a master password reset

---

## 3. Server encryption key

The server encryption key (`encryption_key` file) is used for AES-256-CFB encryption of all data at rest. It is the most sensitive secret in an on-premise Passwork deployment.

### 3.1 Key file location and permissions

```bash
# Linux
ls -la /var/www/init/
# Look for the encryption_key file
# Expected: -rw------- 1 www-data www-data

# Docker
ls -la /<passwork>/conf/keys/
```

Verify:
- [ ] The key file is **not** accessible to the database user, other web applications, or world-readable
- [ ] The key file is **not** stored inside the database directory
- [ ] File permissions: `600` (owner read/write only)
- [ ] File owner: the web server process user (e.g., `www-data`)

**Finding:** If the file permissions are `644` or wider, this is a **high-severity finding**. The key protects all server-side encrypted data.

### 3.2 Key backup storage

The encryption key must be backed up separately from the database backup. If both are stored together, a single breach compromises both the ciphertext and the key.

Verify:
- [ ] The encryption key is backed up independently of the database
- [ ] The key backup is stored in a different physical or logical location than the database backup
- [ ] The key backup itself is encrypted (e.g., using GPG with a separate passphrase)

### 3.3 Key rotation

Passwork does not currently support automated server key rotation. The key remains static after initial deployment. Document the current key age and note this in the security register.

---

## 4. Algorithm compliance verification

Passwork's cryptographic algorithms against current standards:

| Algorithm | Passwork implementation | NIST SP 800-131A Rev. 2 (2019) | Status |
|-----------|------------------------|-------------------------------|--------|
| AES | 256-bit, CBC/CFB | AES-128/192/256 approved | ✓ Compliant |
| RSA | 2048-bit, OAEP/SHA-256 | RSA ≥ 2048 bit approved | ✓ Compliant |
| PBKDF2 | SHA-256, 300,000 iterations | ≥ 310,000 iterations for SHA-256 (NIST 2024) | ⚠ One iteration short per NIST 2024 update |
| SHA-2 | SHA-256 / SHA-512 | Approved | ✓ Compliant |
| CSPRNG | WebCrypto (browser) / OpenSSL (server) | Approved | ✓ Compliant |
| TLS | 1.2+ (1.3 preferred) | TLS 1.2 minimum | ✓ Compliant |

:::info PBKDF2 iteration count
NIST SP 800-132 (2024 update) recommends ≥ 310,000 iterations for PBKDF2-HMAC-SHA-256. Passwork uses 300,000 (client-side) and 600,000 (server-side verification). The client-side count is marginally below the 2024 recommendation; it fully meets pre-2024 NIST guidance (10,000 iterations). This is a low-severity informational note, not a critical finding.
:::

---

## 5. Encryption scope — what the server can see

For compliance documentation, it is important to know which data fields are accessible to the server administrator in each encryption mode.

### With CSE enabled (Zero-Knowledge model)

**Server can read (stored unencrypted or server-only encrypted):**
- Vault names, folder names
- Record names (titles)
- Login/username field
- URL field
- Tags and color labels
- Description/notes field
- File names (not file contents)
- User emails and usernames
- Group memberships, vault access rights, timestamps

**Server CANNOT read (client-side encrypted, Zero-Knowledge):**
- Password field
- Custom field names and values
- TOTP secrets
- File contents
- Record revision history (previous passwords)

### With CSE disabled

The server-side encryption key protects all data at rest, but a party with access to both the database and the `encryption_key` file can decrypt all fields, including passwords.

This is acceptable for organizations where the threat model does not include insider threats from infrastructure administrators, and Passwork runs in a trusted isolated network.

**Document in compliance records:** Whether Zero-Knowledge is required by your security policy or regulatory framework.

Full field-by-field encryption scope: [Encryption scope](https://passwork.pro/tech-guides/cryptography/encryption-scope/)

---

## 6. Backup encryption

Database backups contain all Passwork data. Unencrypted backups stored on accessible media are equivalent to an unencrypted database.

### What to verify

- [ ] Database backups (MongoDB) are encrypted at rest in the backup storage location
- [ ] Backup storage access is restricted to authorized personnel only
- [ ] Backup encryption keys are stored separately from backup data
- [ ] Backup restoration has been tested within the last 6 months
- [ ] Backups are retained for the duration required by your data retention policy

For MongoDB backup configuration, see [Backup creation and restoration examples](https://passwork.pro/tech-guides/databases/mongodb/backup-creation-and-restoration-examples/).

---

## Summary checklist

| # | Control | Status |
|---|---------|--------|
| 2.1 | CSE status is known and verified | |
| 2.2 | CSE decision is documented with justification | |
| 2.3 | If CSE enabled: master password policy ≥ 14 chars | |
| 3.1 | Server encryption key file: permissions 600, correct owner | |
| 3.2 | Encryption key backed up separately from database | |
| 3.3 | Key age documented | |
| 4 | Algorithm compliance documented (NIST); PBKDF2 note recorded | |
| 5 | Encryption scope documented in compliance records | |
| 6.1 | Backups encrypted at rest | |
| 6.2 | Backup restoration tested within last 6 months | |