Zero-Knowledge security model

What is Zero-Knowledge

Zero-Knowledge (ZK) is an architectural principle where the server has no access to decrypted data. All encryption and decryption happens on the client side.

In practical terms: even if an attacker gains full access to the Passwork server and its database, they'll only find encrypted blobs — without user keys, reading secrets is impossible.

How it works

┌─────────────────┐                      ┌─────────────────┐
│     Client      │                      │     Passwork    │
│  (browser/CLI)  │                      │     Server      │
├─────────────────┤                      ├─────────────────┤
│ Encryption keys │   ──── HTTPS ────►   │ Encrypted       │
│ Decryption      │   ◄── HTTPS ────     │ data            │
│ Encryption      │                      │ Metadata        │
└─────────────────┘                      └─────────────────┘

Stored on server	Known only to client
Encrypted passwords and fields	Encryption keys
Encrypted attachments	Decrypted values
Record and folder names	User's master password
Access rights structure	—
Audit log	—

Security benefits

Protection from server compromise

Even with full server access, an attacker cannot:

• read passwords or secrets;
• decrypt attachments (keys, certificates);
• recover values from database backups.

Protection from insiders

Passwork administrators (system admins, DBAs) have no technical means to view secret contents — even with direct database access.

Compliance

Zero-Knowledge makes security audits simpler: you can demonstrate that even privileged infrastructure users cannot access secrets.

tip

In the on-premise version of Passwork, Zero-Knowledge mode can be disabled by the administrator. Consult your security team for the current configuration.

Impact on automation

Zero-Knowledge limits what the server can do on its own.

Server limitations

Operation	Why it can't work server-side
Automatic password rotation	Server lacks encryption keys
Password quality checks	Values are encrypted
Built-in integration with external systems	Requires a client with keys

The solution

For rotation and advanced automation, use an external client — a script or service that:

1. Authenticates with Passwork (obtains tokens).
2. Retrieves and decrypts secrets via CLI/SDK.
3. Performs actions in target systems (databases, services).
4. Encrypts and writes new values back.

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   Rotation   │      │   Passwork   │      │   Target     │
│   script     │ ───► │   (stores)   │      │   system     │
│              │ ◄─── │              │      │  (PostgreSQL)│
│  - CLI/SDK   │      └──────────────┘      │              │
│  - keys      │ ─────────────────────────► │              │
└──────────────┘                            └──────────────┘

Typical setup

# Cron job for rotation
0 3 * * 0 /opt/scripts/rotate-db-passwords.py

What rotate-db-passwords.py does:

1. Lists records in the infrastructure/production/databases folder.
2. For each record:
   • generates a new password;
   • updates the password in PostgreSQL/MySQL;
   • stores the new password in Passwork.
3. Sends a summary to Slack or email.

Implementation examples can be found in:

• Managing secrets via CLI
• Managing secrets via Python SDK

LLM version