Zero-Knowledge password vault
Your passwords, API keys, and secrets — encrypted so that even the server cannot see them. Mathematically proven privacy.
Dual-layer crypto architecture
Company Safe and Personal Vault use different encryption — each optimized for its use case.
Company Safe
Server-side encryption (Laravel Crypt, AES-256-CBC)
- Admin and folder-authorized users can view
- Data preserved when employee leaves
- Folder sharing: user, role, department
- Audit log for every access
Personal Vault
Client-side Zero-Knowledge (HKDF + AES-256-GCM)
- ONLY the owner can see the data
- Server never knows the plaintext
- Password lost — data gone. That's the guarantee
- Even admin cannot access
HKDF key derivation
Architecture inspired by Bitwarden/1Password, where encryption key and authentication key are derived as mathematically separate branches.
Master password
User-chosen password — minimum 8 characters.
input: user passwordPBKDF2 stretching
Master password + random 16-byte salt → 100,000 iterations of HMAC-SHA256. Slows down brute-force attacks.
PBKDF2(SHA-256, password, salt, 100K) → preKeyHKDF stretch
HKDF-Expand adds an extra security layer, deriving preKey into a specific stretchedMasterKey.
HKDF-Expand(SHA-256, preKey, "tresoor-stretch") → stretchedMasterKeyEncryption key (encKey)
AES-256 key used for data encryption. NEVER leaves the browser — the server does not know it.
HKDF-Expand(stretchedMasterKey, "vault-enc") → encKeyAuthentication key (authKey)
Separate branch for password verification. SHA-256 hash is sent to server — server verifies but cannot derive encKey.
HKDF-Expand(stretchedMasterKey, "vault-auth") → authKey → SHA-256 → hashHKDF("vault-enc")encKeybrowser onlyHKDF("vault-auth")authKey → SHA-256hash to serverZero-Knowledge guarantees
Mathematical guarantees that hold even in case of server compromise.
Server never sees plaintext
Encryption happens only in the browser (Web Crypto API). The server stores and returns only ciphertext.
Server doesn't know encKey
Server only holds auth_key_hash — SHA-256 from a separate HKDF branch. No mathematical relation to encKey.
enc ≠ auth
HKDF ensures that "vault-enc" and "vault-auth" branch outputs are cryptographically independent.
Password lost — data gone
There is NO recovery mechanism. This is a core property of Zero-Knowledge architecture, not a flaw.
Admin cannot access
Personal vault returns HTTP 403 to admin requests. Not a policy restriction, but cryptographic — data is encrypted with user's key.
Timing-safe verification
Password verification uses hash_equals() — prevents timing side-channel attacks.
Threat model
Known attack scenarios and their mitigations.
Server compromise
Attacker obtains database clone with all encrypted records.
Man-in-the-middle
Attacker intercepts API calls between user and server.
Brute-force attack
Attacker tries to guess the master password.
XSS (script injection)
If attacker injects JS into the page, they could read encKey from memory.
Insider threat (admin)
Company admin tries to read employee's personal vault.
Rainbow table attack
Pre-computed hash tables for breaking passwords.
Cryptographic standards
| Algorithm | Standard | Usage |
|---|---|---|
PBKDF2-HMAC-SHA256 | RFC 2898 | Password → preKey |
HKDF-SHA256 | RFC 5869 | Key expansion & separation |
AES-256-GCM | NIST SP 800-38D | Authenticated encryption |
SHA-256 | FIPS 180-4 | Auth key hashing |
Web Crypto API | W3C | Browser-native cryptography |
Crypto parameters
PBKDF2— 100 000 iterationsAES-GCM— 256-bit key, 96-bit IVmaster_salt— 128-bit (16 bytes) randomauth_key_hash— SHA-256 (256-bit → 44 Base64 chars)HKDF info— "tresoor-stretch", "vault-enc", "vault-auth"
Your data, your control
Tresoor Vault ensures your passwords and secrets are protected with bank-level encryption — even we cannot read them.