How Pinzen protects your vault

The guarantee Pinzen makes

For a vault using the default recovery setting, a complete snapshot of Pinzen's API state, D1 database, and server environment secrets does not contain the browser-generated 256-bit Account Secret or root material required to derive its v2 vault key. Under the documented cryptographic assumptions, that captured server state cannot decrypt the vault or validate guesses of its master phrase.

A user who explicitly enables Google account recovery chooses a different guarantee: Pinzen stores a server-encrypted recovery copy of the root, so a combined theft of the database and server encryption key can decrypt that opted-in vault. This is a server-compromise guarantee with a clearly labeled exception, not an “unhackable” claim.

Browser-side encryption

The master phrase is normalized and processed with Argon2id, then mixed with a random 256-bit Account Secret generated in the browser. HKDF separates index, item, and factor purposes. AES-256-GCM uses a fresh nonce and authenticated context for every encrypted value.

Captured-server-data resistance

The Account Secret is generated during setup and written to the user-downloaded Recovery Kit. A trusted browser can keep only a locally wrapped copy protected by a non-exportable Web Crypto key. During Pinzen+ device approval, the existing device encrypts the Account Secret to a one-time 3072-bit RSA key generated by the new device; the relay receives only that short-lived ciphertext and deletes it after collection or expiry. For recovery-disabled vaults, a database or API compromise can expose account records, encrypted TOTP material, a server factor share, salts, revision counters, and ciphertext without providing the missing local root. Recovery-enabled vaults instead carry the explicitly documented escrow exception.

Write without revealing

New items are sealed with a vault-specific RSA-OAEP public key and a fresh AES-256-GCM data key. The public key can encrypt a PIN, password, card, or note, but it cannot decrypt any saved item.

Split key material

The RSA private key is encrypted behind a key derived from the local Account-Secret-bound root and a random server factor share. Account sign-in, server state, and vault ciphertext are not sufficient to decrypt PINs, passwords, card details, or notes.

Reveal approval

An account-bound passkey with user verification, including a compatible FIDO2 hardware security key, can start a 10-minute reveal window on the unlocked device. The browser receives a short-lived challenge restricted to that user's registered credentials; the server verifies the signed response, origin, relying-party ID, user-verification flag, credential counter, account, and vault before releasing its factor share. A current six-digit TOTP code or an unused recovery code remains available as a fallback. Requests are rate-limited, challenges and accepted TOTP counters cannot be replayed, and the temporary reveal key is discarded when the window expires, the vault locks, or the user signs out.

Recovery and key changes

The Recovery Kit contains a browser-generated Account Secret and one-time authenticator recovery codes. A separate recovery-root envelope is encrypted in the browser with both that Account Secret and the server factor share released by a fresh six-digit authenticator code. The encrypted envelope may be stored with the vault, but neither it, the database, nor the Kit alone can reset the phrase. The browser can use the two inputs to open the old root, create a new phrase-derived root, and re-encrypt the vault. One-time codes inside the Kit are deliberately rejected for this reset so the two inputs remain separate. A trusted device is another path. Google-linked users may separately enable a lower-privacy email fallback.

Live family vaults

Each family vault has an independent random key and RSA key pair. Its private key and metadata are encrypted, and the family key is wrapped separately to each active member's personal public key. Before inviting someone, the organizer compares the recipient's locally derived 96-bit safety code through another trusted channel; this prevents the server directory from silently substituting a public key. Shared records are sealed independently. When an organizer removes someone, the client generates a new family key pair, wraps the new key only to remaining members, and re-encrypts every shared record before the server commits the revision. D1 compare-and-swap guards prevent stale family writers from applying partial record changes.

Sign-in and trusted devices

Pinzen supports passkeys with user verification, Google sign-in, and optional single-use magic links. It does not offer reusable email-and-password authentication. Signing in locates encrypted data; it never derives a vault key. On a trusted browser, locally wrapped non-exportable keys can reopen the vault without repeating the master phrase or Recovery Kit. An explicit lock or timeout still requires a passkey or authenticator approval before protected values can be revealed.

Secure device approval

Pinzen+ can connect a new device without uploading a Recovery Kit. The new device creates a non-exportable one-time RSA-OAEP key pair and displays a short code cryptographically bound to its public key. After a fresh passkey or authenticator approval, an existing trusted device encrypts the Account Secret directly to that public key. The server relays ciphertext only, expires requests after 10 minutes, and cannot use the public key to decrypt the transfer. The user still enters the master phrase locally, preserving two independent inputs. The Recovery Kit remains the offline fallback.

Tampering and rollback

AES-GCM rejects modified ciphertext. Vault and per-item revisions are authenticated inside their encrypted records, so the API cannot relabel an old item as a newer one. Trusted devices also remember the newest revision they opened. A completely new device cannot independently prove that a malicious storage provider returned the globally newest historical snapshot; that requires an external transparency service or another trusted device.

Browser autofill

The extension receives only website logins through an ephemeral RSA-encrypted pairing channel after authenticator approval. Its local snapshot is encrypted under a WebAuthn PRF-wrapped key and automatically locks after 15 minutes without use. Autofill requires a user click, checks the exact HTTPS origin including its port before and during fill, blocks GET and cross-origin form targets, and never submits the form. PINs, cards, notes, master phrases, and authenticator secrets are excluded.

A website's own scripts can read a password after it enters the page. Recent browser-security research demonstrates that preventing this class of leak requires a protected browser channel, not an ordinary extension API. Pinzen therefore treats the destination website as part of the trust boundary and does not claim that autofill can protect a password from a compromised destination.

Password health

Weak, reused, and non-HTTPS login checks run in the unlocked browser after authenticator approval. Known-breach checks use Have I Been Pwned's padded k-anonymity range protocol: only the first five SHA-1 hash characters are relayed, while complete hashes and matching remain local. This leaks a coarse hash prefix by design, not a password or complete hash. Pinzen does not recommend arbitrary periodic password changes; change a password when it is weak, reused, or exposed.

Offline access

The PWA can keep the latest authenticated encrypted snapshot in IndexedDB and open it read-only when the network is unavailable. API responses are never placed in the service-worker cache. Offline storage does not create a new recovery path and can be removed by browser storage eviction, so portable encrypted backups remain important.

Web and API hardening

State-changing API calls require the configured same origin, authentication and security endpoints use distributed rate limits, request and response bodies are bounded and validated, session cookies are Secure, HttpOnly and SameSite, and responses disable caching and framing. The web app uses a per-request nonce Content Security Policy; the PWA never caches API responses.

Current standards and research

Pinzen's design follows the current NIST SP 800-63B-4 authentication guidance and the WebAuthn Level 3 PRF extension where supported. Its release workflow uses locked dependencies, pinned build actions, software bills of materials, and build attestations modeled on SLSA 1.2. The autofill boundary accounts for the 2025 USENIX study of extension-UI phishing and current research on a browser-enforced secure authentication channel.

Important limits

Malware, a malicious browser extension, a compromised frontend release that serves hostile JavaScript, or someone controlling an already-unlocked device can act with that device's access. Browser-delivered cryptography cannot protect a future unlock from JavaScript supplied by a compromised web host. Auto-lock, short reveal windows, clipboard cleanup, attested extension builds, device security, and careful Recovery Kit storage remain important.

Responsible disclosure

Email security@pinzen.app with a clear description and reproduction steps. Use test data only. Do not access another person's account, degrade the service, or include real secrets.