No master password — anywhere
Other managers add passkeys as a login shortcut on top of a master-password-derived key. Pass 014 derives the encryption key from the passkey's PRF output itself. No password exists to bypass, on the server or on disk.
Server can't read your vault
Entries are AEAD-sealed under a per-vault key, which is wrapped under your account key, which is derived from a per-passkey PRF. The backend stores ciphertext + envelopes. Compromise the server and you have a brick.
You host it
Single Go binary plus nginx. Default storage is SQLite — no external services, no third-party telemetry, no upstream account. Backup is a GPG-encrypted file you keep wherever you want.
Cross-device, by design
Add a new phone or laptop by scanning a one-shot QR code on your already-signed-in machine. Both sides display an 8-hex code; you compare on screen, the owner taps Approve. No password roams.
Share without giving up the key
Vaults can be shared by name to other Pass 014 users. The vault key is sealed for the recipient via X25519 — your machine never hands it to the server, and the server can't forward it.
Autofill in iOS & Firefox
iOS credential-provider extension fills passwords system-wide in Safari and native apps. Firefox extension does the same on desktop. Both run fully offline once your vault is unlocked.
How a sign-in actually works
1
Passkey ceremony
You tap a YubiKey or Face ID. The authenticator returns an assertion plus a PRF output — a 32-byte secret derived from the passkey and a per-account salt.
2
Local key derivation
PRF output → HKDF → device key. Server hands over your account-key envelope (AEAD-sealed under the device key). Decrypted locally. The server never sees the plaintext key.
3
Vault unlocked
Each vault's encryption key is wrapped under either your account key (private) or sealed for you over X25519 (shared). Both unwrap on-device; entries decrypt one at a time on reveal.
Self-host in five minutes
One static Go binary, nginx as TLS terminator, SQLite by default. Tested on a $5 VPS.
# on the server
curl -L https://github.com/berrabou/pass014/archive/main.tar.gz \
| tar -xz
cd pass014-main
sudo deploy/install.sh
# point your DNS at the box, drop in nginx config from deploy/
sudo nginx -s reload
sudo systemctl start pass014Full instructions in deploy/README.md. Single-user, multi-user, family — same setup either way.
Threat model, briefly
- What the server learns
- Your username, your devices' public WebAuthn credentials, when you signed in, the size of your vault, and audit-log entries for membership changes. It does not learn entry contents, entry names, your account key, vault keys, or anything decryptable.
- What a stolen device learns
- Nothing without your passkey. The account key envelope is AEAD-sealed under the device key, which is PRF-derived from the passkey at unlock time. No passkey, no device key, no key.
- What sharing leaks
- Membership rows are visible to vault owners; the recipient's public X25519 key is visible to anyone signed in (it's what sealing-for-recipient needs). Vault contents stay sealed.
- What a compromised server can do
- Refuse to serve vault payloads (DoS), serve old vault versions (replay), or lie about who's a member of which vault. It cannot decrypt anything — your encryption key never reaches the server. Frontends are bundled with each client binary (Tauri desktop, native iOS, Firefox extension), so the server never gets to serve JavaScript either.
- What stays on your device
-
For offline reads and autofill, the iOS app caches an
AEAD-sealed snapshot of each vault on disk and stores the
vault key in the biometric-gated Keychain. Lose the phone and
bypass Face ID, and the cache is at risk — same posture as
any password manager that offers offline mode. See
docs/security-model.mdfor the full breakdown.
Get the code
Pass 014 is open-source under the MIT license. Backend (Go), desktop app (Tauri + React), iOS app (SwiftUI + Rust via UniFFI), and Firefox extension all live in one workspace.