Threat model

A security architecture is only meaningful relative to the attackers it assumes. This page states which threats PulsVault's design addresses, how, and — just as importantly — which threats are out of scope or accepted as residual risk.

In scope: attacker models and mitigations#

Threat	Mitigation
Database breach	All secret fields are ciphertext envelopes; keys exist only as wraps. The attacker gets blobs and BCrypt hashes, no decryption path.
Full server compromise	The server never holds the UMK, KEK, or any DEK. There is nothing to exfiltrate that decrypts vault data.
Master-password brute force	Slow key derivation (PBKDF2 ≥ 600k iterations) plus the ~155-bit-entropy Access Key as a second input make offline guessing infeasible.
Stolen Access Key alone	Cannot authenticate without the master password; unlocking the recovery wrap additionally requires the stored wrapper blob.
Online credential guessing	Progressive delays, account lockout, automatic IP blocking, and enumeration-safe error responses.
Man-in-the-middle / replay	HSTS and strict CORS, HMAC request integrity, nonce + timestamp replay rejection — and secrets are already client-side encrypted, so intercepted traffic carries ciphertext inside TLS.
Stolen login token (JWT)	The two-gate model: vault endpoints also require a vault session. A JWT alone returns, at most, ciphertext. Every login token names the session it was issued for, so ending that session (sign-out, a revoked session, suspension) ends the token too; tokens are also revocable via a JTI blacklist.
Session hijacking	Vault sessions are short-TTL and bound to user, login session, IP, and device fingerprint; the UMK auto-wipes on expiry; hijacking signals (IP/user-agent change) raise alerts.
Browser storage theft	A persisted UMK is AES-GCM encrypted under a per-user, per-session HKDF key derived from the PDS — reading storage without the user's password yields nothing.
Compromised sharing recipient	DEK wraps are per-recipient; revocation triggers client-side DEK rotation so the old key stops mattering (see Vault sharing).
Unlock-approval phishing (trusted device)	User-verified number match, 120-second request TTL, biometric gate, and sealed-box delivery the server cannot read.
Insider tampering with history	The hash-chained, HMAC-signed audit log makes modification of past events detectable.

Out of scope#

No password manager can defend a fully compromised endpoint. The following are explicitly outside the model:

• Malware on the user's device — a keylogger or memory scraper on the machine where decryption legitimately happens can capture what the user can see. Mitigations (short vault session TTLs, biometric gates on mobile) reduce the window, not the possibility.
• Coerced or phished users — a user who discloses their master password and Emergency Kit hands over the account; 2FA and number matching raise the bar but cannot eliminate this.
• Weak master passwords — the policy enforces complexity, but ultimately entropy is the user's contribution; the Access Key compensates for offline attacks, not for a guessed password on a device that also holds the Emergency Kit.

Residual risks — accepted and disclosed#

Related#

• Security architecture overview
• Security invariants — the guarantees behind the mitigations
• Best practices — reducing the risks that remain yours