pock

authentication

applies to: sign-in

Touch ID and passwordless unlock

Pock lets you unlock your vault with a fingerprint or hardware key - no password typed, no key sent to the server. Here's the mechanism that makes it work while preserving the zero-knowledge guarantee.

The problem with biometric unlock

Most password managers that offer biometric unlock are making a tradeoff: they decrypt your vault server-side (or on a trusted enclave they control) and send plaintext to your device. The biometric just authenticates you to their server. The server still holds the keys.

Pock's zero-knowledge property requires that the server never sees your decryption key - even during biometric unlock. This is possible through a WebAuthn extension called PRF (Pseudo-Random Function).

WebAuthn PRF

WebAuthn is the standard behind passkeys, Touch ID on the web, and hardware security keys like YubiKey. Most people know it as an authentication protocol: you prove you have a device and optionally a biometric.

The PRF extension goes further: during a WebAuthn assertion, the authenticator (your device's Secure Enclave, or the hardware key) can compute an HMAC over a salt you provide and return the output. This output is deterministic given the same credential and salt: the same value every time you authenticate on that device. It's computed inside the secure hardware and never exposed to the browser's JavaScript context as a raw key.

PRF output = HMAC-SHA-256(credential-secret, salt)

Computed inside Secure Enclave / TPM. Never leaves the authenticator as a raw value.

How Pock uses it

The unlock key is derived from your biometric and used entirely on-device - it never crosses to the server.

When you enable Touch ID for vault unlock, Pock performs a one-time enrollment:

  1. Your passphrase (or recovery code) is used to unlock the Account Unlock Key (AUK) as normal.
  2. A fresh salt is generated and a WebAuthn PRF assertion is made against your device. The PRF output is a 32-byte value derived from the device's credential and the salt.
  3. The PRF output is used as a key-encryption key. The AUK is wrapped (encrypted) using this key and stored server-side alongside the salt.
  4. The PRF output is discarded. Only the wrapped AUK and the salt are persisted.

On subsequent unlocks, Pock fetches the salt and wrapped AUK, triggers a new WebAuthn PRF assertion (which prompts Touch ID), recovers the same PRF output, and uses it to unwrap the AUK locally. Decryption happens on your device. The server sees the salt and the wrapped AUK. It never sees the PRF output or the AUK plaintext.

The per-device model

Each device you enroll creates its own credential and its own PRF-wrapped AUK. Your MacBook's Touch ID enrollment is independent of your iPhone's Face ID enrollment. Revoking a device revokes only its wrapped AUK; all other devices continue to work.

This is the same per-device model used by passkeys. The underlying credential key pair lives in the Secure Enclave and never leaves the device - even Apple cannot extract it. Pock's PRF unlock inherits that property.

What happens if you lose your device?

Your passphrase and recovery code are the fallback unlock methods. They use two-secret key derivation (passphrase + device Secret Key) so a server breach alone cannot brute-force them, but they do not require the lost device. This is why printing and storing the recovery code somewhere safe matters - it is the unconditional backup.

Browser support

PRF is part of the WebAuthn Level 3 specification. Chrome and Edge support it today on macOS (Touch ID), Windows (Windows Hello), and with compatible hardware keys. Safari has broader WebAuthn support but PRF availability depends on macOS version. Firefox support is improving. The Pock web app shows a fallback to passphrase unlock when PRF is not available in the current browser.

Related reading: zero-knowledge model, the vault. Ready to try it? Get started.