Password Manager Recommendations

From password reuse to vault encryption, TOTP, FIDO2, passkeys, autofill and backups—with diagrams and expandable technical notes.

Published October 25, 2026·About 20 min read·Reviewed translation

Copy link

On this page 01 /Why you should not keep reusing the same password

02 /If passwords are in the cloud, why might the provider be unable to read them?

03 /How do Bitwarden and 1Password differ?

04 /Where do those six OTP digits actually come from?

05 /Why are FIDO2 and passkeys more phishing-resistant than manually entered OTPs?

06 /I still prefer keeping TOTP separate from the vault

07 /Autofill is convenient, but it has its own security boundaries

08 /The order I would use to get started

09 /Want more technical detail? Expand the algorithms

↗ /References

These days, every website seems to require an account and a password, but I suspect most people reuse the same set of passwords.

That is dangerous. The real problem is that once one website suffers a leak, someone can take the leaked credentials and try them on other websites.

To help prevent this, there are one-time passwords (OTPs)—although many people find them inconvenient and avoid enabling them—and password managers.

For many people, their password manager is the one built into Chrome. But what happens when they need a password in another app, or somewhere outside the browser?

That is why I want to introduce password managers.

A clarification: on some mobile systems, Chrome/Google Password Manager can also fill passwords in other apps; it is not limited entirely to websites. My main concern is whether I can keep a consistent workflow across devices and browsers.[14]

Credentials leaked

An attacker obtains an account name and password

[email protected] password: ●●●●●●

Try them elsewhere

Website BMay log in

Website CMay log in

Website DMay log in

✓Use a different password on every website, so a leak at A does not directly expose the passwords for B and C.

This attack is called credential stuffing: attackers do not need to crack every website. They can take a list of credentials leaked from website A and automate attempts against websites B, C and D. If any of those sites uses the same password, a login may succeed.

A password manager addresses this problem by generating a different random password for every website, such as a random 20-character string. You only need to remember the manager's master password, not every site's password. Even if website A is compromised, that password cannot directly be used to log in to website B.

A password manager is therefore not a replacement for OTP or FIDO2. It first addresses the difficulty of managing a large number of website passwords safely.

A password manager usually stores your data in a vault. It can sync across devices, but the key point is: encryption and decryption happen on your device. The server primarily receives encrypted data; it does not open the safe for you every time.

Master passwordThe one you remember

→

Unlock the vault locallyKeys are used only in an appropriate device environment

↔

Encrypted syncThe server stores ciphertext

Website Ak8@V!9p...Q

Website BT3#n2Y...w

Website CbP7$4x...M

The strings above are examples only; do not use them as real passwords. This diagram is simplified. The detailed key hierarchy is in the technical notes.

Using Bitwarden's usual master-password flow as an example, we can split it into three layers: first, a KDF turns the master password into key material; that material then unlocks a protected symmetric vault key; only then does the vault key unlock the stored website passwords. This design is called a key hierarchy.[01]

The server also holds data needed for login and operations, but that is not the same as holding vault plaintext.

Conceptual illustration: the real implementation also includes item-level encryption keys, login hashes and other steps. Not every product uses the same key names.[01]

Do not read “zero knowledge” as “absolutely secure,” either. If your computer is already compromised and you unlock the vault, malware may still obtain data from the screen, memory or filled-in fields. Stolen cloud storage and control of a device in use are different threats.[01]

These are the two I would look at first. Neither simply stores plaintext passwords in the cloud, but their designs differ somewhat for the scenario in which cloud backups fall into an attacker's hands.

This would be my first recommendation. The free plan is sufficient for many people, and it offers browser extensions, desktop and mobile apps, and autofill.

It is worth considering first if you value source-code transparency and self-hosting flexibility; self-hosting means taking responsibility for updates and backups.[01]

If you do not mind paying, I would also recommend it. Its interface is well integrated, and it adds a Secret Key to reduce the risk of decryption by guessing only the master password after a server-side data leak.

Keep the Secret Key safe along with your recovery materials.[04]

Both still require a strong master password. 1Password's Secret Key is not a second password to memorize; it is usually stored on authorized devices and in the Emergency Kit. If a device is also compromised, the threat model changes.[04]

Bitwarden offers publicly available source code, cross-platform apps and self-hosting flexibility. It is attractive to people who want to understand the key flow and control their own deployment. But self-hosting is not a magical encryption upgrade: TLS, updates, backups, monitoring and disaster recovery become your responsibility.[01]

1Password protects the vault using a high-entropy, device-generated Secret Key together with the Account Password, while SRP handles login authentication. This primarily adds a barrier when server-side data is leaked but the attacker cannot obtain your device secret; it does not guarantee isolation when an authorized device is infected.[04][19]

As for LastPass, I do not currently put it among my first choices. The reason is the long-term risk left by the 2022 backup breach: attackers may retain vault ciphertext and continue trying weak master passwords in the future. That does not mean every user's passwords were leaked in plaintext.[15]

Many websites ask you to enable OTP and scan a QR code, after which your phone shows a new six-digit number periodically. A common implementation is TOTP（Time-based One-Time Password）. The server does not send a new password to the phone every 30 seconds.[11]

During initial setup, the website generates a secret seed and passes it to an authenticator such as Authy through a QR code. After that, the website and phone independently calculate using the same seed and time window, so their results agree. This also explains why the phone can often generate verification codes without an internet connection.

The numbers and timeline illustrate the principle; these are not usable codes. The service determines the actual time tolerance, HMAC algorithm and number of digits.[11]

TOTP can stop someone who has stolen only your password, but not your phone or seed, from logging in directly. However, the six digits are not bound to the real website's domain: if you enter a code on a fake login page, an attacker may immediately relay it to the real website. That is the problem FIDO2 addresses in the next section.[12]

A six-digit TOTP is an answer that can be passed along. FIDO2/WebAuthn works differently: at registration, a security key or device generates a Private Key / Public Key pair; the website stores only the Public Key. At login, the website sends a one-time Challenge, which the authenticator signs using the Private Key and the website verifies.[13]

An attacker may relay the code before it expires.

The browser/authenticator enforces domain constraints; the server must also verify the Origin, Challenge, signature and other conditions.

This describes standards-compliant, correctly implemented WebAuthn login. It cannot prevent theft of an authenticated session, nor fix weak account-recovery options that a website still offers.[12][13]

Passkey is a sign-in experience built on FIDO credentials that usually removes the need to enter a traditional website password. A passkey can stay on specific hardware or sync in encrypted form within a supported ecosystem. These approaches have different device-loss and recovery risks.

Also, YubiKey is a hardware product; FIDO2 is a protocol. A compatible security key may support traditional OTP, TOTP and FIDO2. Plugging in a physical key does not automatically provide WebAuthn's phishing resistance.[21]

I still recommend Authy, and I would try to keep TOTP separate from the vault—not just in a different system, but preferably on separate hardware.

This is not because two apps merely sound safer. The goal is to avoid a single point of compromise exposing both the password and second factor. If website passwords and TOTP seeds are in the same unlocked vault, an attacker who can read the entire vault may obtain both secrets together.[20]

Vault

Website passwordsTOTP seeds

If the whole vault is read, both sets of secrets may be compromised together.

My preferred approach / Separate devices

ComputerVault / Passwords

Stored separately

PhoneAuthy / TOTP

For important accounts that support FIDO2, I would prefer a separate physical security key.

Separation does not prevent every phishing attack: TOTP codes can still be relayed in real time. FIDO2/WebAuthn provides domain-specific protection.

The most convenient option, and not necessarily unreasonable for ordinary low-risk sites; but a compromise of the entire vault may expose both secrets.

For example, Bitwarden on the computer and Authy on the phone. This can reduce the consequences of a single-vault compromise, although shared backup accounts also matter.

For your primary email, cloud, financial and administrator accounts, prioritize FIDO2 where supported. Prepare a second key so losing one does not leave you unable to recover.

Suitable for people who want to manage TOTP separately on a phone. Backups can sync in encrypted form, but do not keep the backup password only in the same vault.[06]

Note: Authy's Windows, macOS and Linux desktop apps reached end of support in March 2024; it now primarily uses mobile apps. Once you have set up a backup device, the official recommendation is to disable the Multi-Device option that allows new devices to be added.[08] [07]

Twilio does not keep or recover your Authy backup password for you. If you enable backup sync, you must be able to find the backup password yourself; do not lock it in the same place as the vault's only recovery method. After disabling the addition of new devices through Multi-Device, make sure you still have a working backup device or recovery route.[06][07]

Other options worth comparing include 2FAS, Aegis, Ente Auth and Yubico Authenticator. What matters is not the app's popularity, but where it stores seeds, whether it supports encrypted backups, whether you can recover after losing your phone, and whether it is truly isolated from your main vault.

Autofill is a useful option, especially since many apps read the clipboard.

Modern Android and iOS versions impose permissions, prompts or background restrictions on clipboard access; not every app can peek at it at any time. Still, putting a password on the clipboard adds an exposure path. System-integrated autofill avoids having to copy and paste it each time.[10][17]

Autofill does not make a malicious app safe: if you actively fill a password into a fake login screen, it may still be captured.[09