Comparison with similar systems
fido2box is designed for getting back into other accounts after losing your devices: keep a few recovery secrets in an encrypted file, then open it through a static site with an enrolled authenticator. Its distinguishing choice is this combination of recovery workflow, file ownership, and browser-based PRF unlocking. The README describes that intended use; the security boundaries qualify what the current implementation guarantees.
Research checked 2026-10-07, using the official sources linked below. This compares documented workflows, not security strength or every product feature. Bitwarden and 1Password rows describe ordinary personal accounts; Passpack describes its team service. Organization policies and alternative sign-in configurations can change dependencies. Passpack sources were available through indexed official pages; direct retrieval failed during this review.
Workflow and storage
Here, an account means an account with the vault or storage service, not the website credentials stored inside a record. Every system can hold recovery information; the daily-use column describes its documented workflow.
| System | Daily use or recovery use | Vault/service accounts | Storage and deployment |
|---|---|---|---|
| fido2box | Recovery-first: named fields, optional addresses, per-value copy. README | No fido2box account; optional GitHub backup requires repository access. README | Static site, no backend; encrypted browser storage, JSON downloads, optional explicit GitHub Push/Pull. README |
| Bitwarden | Daily password management with browser saving and autofill. Browser guide | Account on a selected cloud region or self-hosted server. Server regions | Hosted service or a deployed Bitwarden server. Hosting |
| 1Password | Daily password management with browser saving and filling. Browser guide | A 1Password account provides access across devices. Sync guide | Service-synchronized vaults, with local access after synchronization. Sync guide |
| KeePassXC | Desktop password management using an encrypted database. Overview | Local files need no vault-service account; optional cloud storage adds access requirements. FAQ | Local KDBX file; optional synchronization through a chosen file-sync service. FAQ |
| KeeWeb | Browser and desktop password management, with search and password generation. Features | Local files need no KeeWeb account; optional cloud storage adds access requirements. FAQ | KDBX files; static web hosting or desktop app, optional cloud sync. FAQ, features |
| Passpack | Team password management with shared records, custom fields, and browser access. Glossary | Passpack user accounts within an organization; configured SSO is available. Glossary | Hosted service: device-side encryption before server storage; extension keeps encrypted local copies. Privacy |
Keys and recovery
| System | Hardware-key role | What recovery depends on |
|---|---|---|
| fido2box | WebAuthn PRF unwraps the data key; user verification required, hardware-only enrollment unenforced. Security | Box file, enrolled authenticator and verification, compatible browser, original domain/RP identity. Recovery, security |
| Bitwarden | FIDO2/passkey account 2FA; separately, encryption-enabled PRF passkeys can decrypt the vault. 2FA, PRF | Account/server access and an unlock method, or a prepared recovery route. Recovery options |
| 1Password | The documented security-key setup provides account two-factor authentication. Security keys | Password-based sign-in needs account details, Secret Key, password, and enabled 2FA; recovery codes offer another route. Kit, codes |
| KeePassXC | Optional YubiKey/OnlyKey HMAC-SHA1 challenge-response contributes to database encryption. FAQ | Database backup and its configured password, key file, and hardware-key components. User guide |
| KeeWeb | Documented YubiKey challenge-response protects the database master key in desktop apps only. YubiKey guide | KDBX file, password/key file, and any configured hardware-key protection. FAQ, YubiKey guide |
| Passpack | YubiKey account MFA documented; FIDO2/PRF vault decryption unverified in reviewed sources. Security | Service/account access, configured unlock method (Packing Key/device registration), and required MFA. Security, Packing Key |
Recovery details depend on how each system was configured:
- Bitwarden: a two-step recovery code still requires the master password. Prepared emergency access or organization recovery may provide other routes. 2FA recovery, recovery options
- 1Password: a prepared recovery code requires email access and leaves enabled 2FA in place. Recovery codes
- KeePassXC: a duplicate challenge-response key needs the same programmed HMAC secret. User guide
- KeeWeb: the application cannot reset forgotten database passwords or recover lost key files. FAQ
- Passpack: preserve the administrator's Packing Key in a Data Recovery Kit; Passpack cannot reset it. An administrator can reset a team member's Packing Key. MFA emergency codes address lost second-factor access separately. Packing Key, team-member reset, MFA recovery
What the distinction means
Authenticator-assisted encryption is not unique to fido2box. Bitwarden documents PRF-based vault decryption, while KeePassXC documents challenge-response in the database key. A security key used for account 2FA authenticates a login; that fact alone does not mean its output encrypts the vault. 1Password's security-key guide describes that second-factor role. KeeWeb is a close architectural comparison because its web app can also run on a static server.
For fido2box, owning the file removes the need for a vault-service account, but does not remove operational dependencies. Preserve the box outside the browser, enroll a spare key in advance, retain the production domain, and rehearse the full recovery path. A copy accessible only through the account you are trying to recover creates a circular dependency. GitHub synchronization is optional; a downloaded box can be imported without it. See recovery and backups.
The static site and browser remain trusted while unlocking: the browser receives plaintext and data-key material, and compromised served code could misuse that access. Enrollment currently permits platform authenticators, so “hardware key plus PIN” describes the intended workflow rather than an enforced hardware-only guarantee. The remaining findings in issue #16 include ineffective key revocation and unauthenticated vault structure and revision. The record implementation separately addresses stale unlocked state after Pull. See security boundaries and the audit notes; this comparison does not establish cryptographic assurance.
Recovery records
Records contain a title and ordered named fields, with independent text, multiline or URL kinds and hiding choices. URLs are optional; each value has Copy, and permitted URLs are links. Optional secret confirmation is transient. Legacy migration retains a verified encrypted original; older releases cannot safely edit the new format. See the README and recovery guide. These conventions do not establish interoperability or support for another product's vault format.