Password Managers

Category overview · ProPrivacyTime

A password manager is a custodian for one file that matters more than almost anything else in your cloud. The vault it stores — your logins, the notes that hold answers to security questions, the recovery codes for your email and bank — is a single encrypted file whose compromise or loss is more damaging than almost any other file you keep online. That is the core trust trade of the category: you are handing one file, and the key to it, to a third-party custodian, in exchange for not having to remember dozens of strong and distinct passwords yourself.

We treat password managers as infrastructure, not gadgets. The decision that should dominate your evaluation is not "which one has the nicest browser extension" but "who holds the key, what happens when I lose it, and how do I leave." Architecture, recovery semantics, and exit paths matter more than feature lists, because the feature lists have converged: every serious product now offers unlimited passwords, cross-device sync, a browser extension, and some form of secure sharing. Once the basics are met, what separates products is structural and is readable in their published material.

How we evaluate password managers

We read what vendors actually publish — security whitepapers, audit summaries, support documentation, and the fine print of account-recovery flows — rather than running our own speed tests or infection simulations. Our criteria, all answerable from public documents, are:

• Encryption architecture. Whether the product is zero-knowledge: the vault is encrypted on your device, the key is derived from your master password and never sent to the server, and the company's servers hold only ciphertext. We read the whitepaper for where decryption happens and what fields, if any, remain in plaintext metadata.
• Recovery semantics. What actually happens if you forget the master password, and whether any recovery path lets the vendor reconstruct your key. A recovery flow that can reconstitute your master password at the vendor's end is disqualifying, because it means the vendor can read your vault.
• Export and portability. The exit path. Whether the product exports a complete, usable vault (logins, secure notes, attachments, TOTP seeds) or only a partial one, and in what format.
• Audit history. Whether independent security audits are published, how recent they are, and how candidly the vendor discusses what was found and fixed.
• Account model. Individual, family, or business; what an admin can override; and whether emergency-access or heir features are end-to-end encrypted.

Common misconceptions

• "The browser built-in is just as good." Built-in managers are convenient and better than reused passwords, but most do not offer zero-knowledge cloud sync across ecosystems, granular sharing, or a documented emergency-access path. "Good enough" and "auditable" are different claims.
• "If I forget the master password, it's recoverable." In a genuine zero-knowledge design it is not — by construction, the vendor cannot decrypt your vault, so it cannot reset your master password either. Recovery exists only through mechanisms you set up in advance (a recovery key or a designated heir).
• "A password manager is a single point of failure." It is, which is the argument for using one well: a strong master password, an offline-stored recovery kit, and a tested export are what turn a single point into a managed one. The alternative — dozens of reused or weak passwords — is a far larger concentration of risk.
• "Open source means automatically safe." Source availability lets anyone inspect the code; it does not guarantee the deployed service matches the published code, that audits were performed, or that the key-derivation parameters are sound. Open source is a precondition for trust, not a substitute for it.

Where to start

If you are choosing a manager for the first time, read the guide below before looking at feature tables. It frames the four questions that outlast any comparison.