Pass014 — passkey-only password manager

No master password — anywhere

Other managers add passkeys as a login shortcut on top of a master-password-derived key. Pass014 derives the encryption key from the passkey's PRF output itself. No password exists to bypass, on the server or on disk.

Hardware-bound, never synced

Register a device-bound Secure Enclave key — Touch ID or Face ID that never leaves the machine and never syncs to iCloud Keychain. Flip on hardware-only mode and the server refuses syncable passkeys outright, so your vault's root key can't leak through someone else's cloud account.

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 Pass014 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 logins in Safari and any app that publishes its associated domain — from a local AEAD-sealed snapshot, no network needed once the vault is unlocked. The Firefox extension handles desktop-browser login + fill.

How a sign-in actually works

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.

Local key derivation

PRF output (or a Secure Enclave ECDH) → 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.

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 on a small box

One static Go binary, nginx as TLS terminator, SQLite by default. Small enough to run on a $5 VPS.

# build + install the binary + systemd unit + admin token
curl -L https://github.com/berrabou/pass014/archive/main.tar.gz \
  | tar -xz
cd pass014-main
sudo deploy/install.sh

# then: edit /etc/pass014/config.env, drop in deploy/nginx.conf
# template (Let's Encrypt covered in deploy/README §6),
# `systemctl start pass014.service`, and you're up.

Full six-step walk-through in deploy/README.md — config, systemd, nginx, TLS. 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 reconstructed from your passkey or Secure Enclave only at unlock time — and no bearer token sits on disk either. 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.md for the full breakdown.

Get the code

Pass014 is open-source under the AGPL-3.0 license. Backend (Go), desktop app (Tauri + React), iOS app (SwiftUI + Rust via UniFFI), and Firefox extension all live in one workspace.

GitHub Design docs