Security-first password manager for your business

Passwork applies two independent encryption layers:

The server layer is always active. All data at rest is encrypted with AES-256-CFB via OpenSSL. This protects against database file theft even without client-side encryption.

The client layer runs when client-side encryption (CSE) is enabled. Sensitive fields are encrypted on the user's device before leaving it. The server receives already-encrypted data and adds a second layer on top.

On Passwork Cloud, CSE is always enabled and cannot be disabled. On on-premise installations, CSE is configurable — disabling it is acceptable for air-gapped environments with documented justification, but is a high-severity finding on any internet-accessible instance.

Each piece of data is protected by a chain where each level encrypts the next:

1. The user enters the master password — it never leaves the device
2. PBKDF2 (SHA-256, 300,000 iterations) derives a 512-bit master key in the browser
3. The master key decrypts the user's private RSA key (2048 bits, OAEP/SHA-256), which is stored on the server in encrypted form
4. The private RSA key decrypts the vault key (256 bits), which is unique per vault and stored RSA-encrypted per user
5. The vault key decrypts the record key (256 bits), unique per record
6. The record key decrypts the password field, custom fields, TOTP secret, and attachment keys
7. Each attached file has its own unique attachment key (256 bits), encrypted with the record key

Compromising a single record key exposes only that one record. It does not expose other records, other vaults, or the user's RSA key.

All algorithms meet or exceed NIST SP 800-131A Rev. 2 recommendations:

• • AES-256 — symmetric encryption (CBC on client, CFB on server via OpenSSL)
• • RSA-2048 OAEP / SHA-256 — asymmetric key exchange between users; generated via WebCrypto API
• • PBKDF2 — key derivation from master password: 300,000 iterations (SHA-256) on the client, 600,000 iterations (SHA-512) on the server for login password hashing
• • TLS 1.3 — all network connections; TLS 1.0 and 1.1 are disabled
• • CSPRNG — all keys, IVs, and tokens use cryptographically secure generators: WebCrypto in the browser, OS-level generators on the server (getrandom() on Linux, CryptGenRandom on Windows)
• • PBKDF2 salts — 20 characters, ~120 bits entropy, unique per user, server-generated

Each key uses a fresh 128-bit initialization vector per encryption operation. Vault and record keys carry ~596 bits of input entropy, reducing to 256 bits through the AES key derivation step.

• • ISO 27001 certified (2024) — covers development, infrastructure, and operational practices
• • GDPR compliant — data minimization, retention controls, right to deletion, data portability
• • Tested by HackerOne — independent penetration testing covering OWASP Top 10, SANS Top 25, authentication flows, API authorization, management, and resilience against advanced persistent threats
• • NIST SP 800-131A Rev. 2 — all cryptographic algorithms comply; AES-256 and RSA-2048 are approved; PBKDF2 iteration counts are within NIST guidance

Passwork also publishes a machine-readable security profile at passwork.pro/trust.json and a standard security.txt contact file.

Every feature goes through six mandatory stages before release:

1. Idea stage — security requirements analysis and Security Champion review
2. Analysis — STRIDE threat modeling and specification
3. Code — SAST (static analysis), SBOM checks on all dependencies, automated tests
4. Build — isolated CI environment, signed distributives, private keys stored offline
5. Testing — DAST (dynamic analysis), AI-assisted review, manual expert verification
6. Release — signature verification on the customer portal

All distributives are cryptographically signed. Builds are assembled in an isolated CI environment with no external access. Private signing keys are stored offline. The public key is available at passwork.pro/public-key. Signature verification is built into the deployment scripts, so installations automatically confirm integrity before proceeding.

All user and system actions are recorded in an immutable action history. The log captures authentication events, admin actions, vault access changes, password exports, API token creation, and LDAP sync results. Events are exported in CEF (Common Event Format) via Syslog, compatible with Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM, and ArcSight. On Windows Server, events are written to Windows Event Viewer.

Recommended retention:

• • General use: 90 days minimum
• • ISO 27001: 1 year
• • PCI-DSS: 1 year, with 3 months immediately available

The Security Dashboard continuously analyzes vault credentials and flags weak passwords, passwords not rotated in over 180 days, and credentials that were accessed by users whose access has since been revoked — the last category is a critical finding requiring immediate rotation.