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]
01 /Why you should not keep reusing the same password
✓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.
Password reuseA leak in one place may affect other accounts.
Phishing websitesTrick you into entering a password; unique passwords alone do not guarantee protection.
Compromised devicesMay expose credentials while you use them; endpoint security must address this.
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.
02 /If passwords are in the cloud, why might the provider be unable to read them?
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.
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.
It is not simply “the master password directly encrypts everything with AES”
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]
01 · You enterMaster PasswordA human-memorable secret
↓ PBKDF2 / Argon2id, HKDF
02 · DeriveStretched Master KeyUsed to unlock the protected key
↓ Unwrap
03 · Obtainsymmetric vault keyDecrypt website passwords locally
← Sync ciphertext← Protected Symmetric KeyThe server does not decrypt the plaintext →
Encrypted VaultEncrypted account data
Protected KeyStill needs local unwrapping
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]
What do KDFs, AES and MFA each do?
KDFDeliberately make each master-password guess computationally more expensive; they cannot turn a weak password into a strong one.
AES + integrity verificationProtect stored vault contents against direct reading or undetected modification.
MFA / two-step verificationAdd requirements for logging in to an account; they do not stop an attacker from guessing offline against ciphertext already stolen.
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]
03 /How do Bitwarden and 1Password differ?
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.
BitwardenOpen source · Cross-platform
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]
1PasswordSubscription · Integrated experience
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]
Bitwarden
Vault ciphertext＋Guess the master password→The KDF makes each guess more expensive
1Password
Vault ciphertext＋Guess the Account Password＋The Secret Key is also needed
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]
04 /Where do those six OTP digits actually come from?
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.
Initial setupThe website creates secret seed K
→ Scan QR code →
Your phoneAuthy stores the same K
Every subsequent login · Each side calculates independently
WEBSITE
HMAC(K, time window T)
482 916
The server calculates and compares locally
＝Same K
Same T
AUTHENTICATOR / Phone
HMAC(K, time window T)
482 916
Can generate codes offline
Time window T
00–29 seconds
30–59 seconds
The next 30 seconds
The time window changes → The code usually changes too
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]
05 /Why are FIDO2 and passkeys more phishing-resistant than manually entered OTPs?
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]
Using TOTP
Fake websiteCapture six-digit code →Real website
An attacker may relay the code before it expires.
Using FIDO2/WebAuthn
Fake domainRP ID mismatch ×Credential for the real domain
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]
06 /I still prefer keeping TOTP separate from the vault
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]
Separation does not prevent every phishing attack: TOTP codes can still be relayed in real time. FIDO2/WebAuthn provides domain-specific protection.
I would divide separation into three levels
01Passwords and TOTP in the same vault
The most convenient option, and not necessarily unreasonable for ordinary low-risk sites; but a compromise of the entire vault may expose both secrets.
02Different apps, with TOTP on another phone
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.
03A separate hardware security key, preferably using FIDO2
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.
Authy
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.
07 /Autofill is convenient, but it has its own security boundaries
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] [10]
How does the manager know which website you are on?
For a browser extension, a password manager typically compares the current page's URL／URI with the address saved in the vault. Bitwarden's default Base domain works for most websites, but you can choose Host or Exact to reduce suggestions on subdomains where you do not want to fill credentials.[18]
Base domainDifferent subdomains under example.com may all
match.
HostLimited to the hostname login.example.com.
ExactThe entire URL must match exactly; this is stricter, but redirect parameters may cause a mismatch.
However, an autofill suggestion is not a guarantee that a website is trustworthy. If the site itself is compromised or has malicious fields, it may still read a filled password. Bitwarden warns about or blocks certain untrusted iframes, so I would turn off autofill on page load and trigger it with a keyboard shortcut or manually when needed.[09]
Mobile autofill typically relies on operating-system services and information such as app identity and associated domains. It may not make the same fine-grained URL-path decisions as a desktop browser. Even secure autofill does not automatically make a malicious app safe.
08 /The order I would use to get started
-
01
Choose a unique, long, hard-to-guess master passwordDo not reuse it on any website. Consider a randomly generated multiword passphrase instead of a birthday plus a predictable pattern.
-
02
Give each frequently used website a unique passwordUse the manager to generate long random passwords. Start with email, cloud and financial accounts, and sites where you have reused passwords.
-
03
Add a second factor to the vault login itselfPrefer a FIDO2 security key where supported; otherwise use TOTP on a separate phone. Do not keep the only MFA secret inside the very vault you need it to open.
-
04
Use autofill, but keep the confirmation stepCheck the domain or app, disable autofill on page load, and consider Host or Exact URI matching for sensitive services.
-
05
Prepare independent recovery routes for root accountsYour primary email, password manager and passkey-sync account should not depend on a single circular recovery chain.
-
06
Back up encrypted exports and actually test recoveryFor Bitwarden, consider password-protected encrypted JSON. Handle attachments separately; an ordinary ZIP is not an encrypted backup.[16]
-
07
Keep the system updated and lock the vault regularlyRemove unnecessary browser extensions, and do not unlock the vault on untrusted shared devices.
Cannot log in to the vaultNeed TOTP / recovery codesBut the only copies are in the vaultA circular dependency
Keep recovery capability separateOffline recovery codesA backup FIDO2 key or separate phoneActually test recovery
09 /Want more technical detail? Expand the algorithms
The sections above explained why these practices matter. Below are the key flows, formulas, protocol checks and exceptions; open whichever part you want to explore.
01 · Bitwarden's key hierarchy: from Master Key to vault plaintext
For a typical Bitwarden account using a master password, the client runs a KDF with inputs including the master password and account email to obtain the Master Key. HKDF then expands it into the Stretched Master Key, which unlocks the Protected Symmetric Key retrieved from the server to obtain the User Symmetric Key. Data is decrypted on the client. This is a conceptual flow that omits item-level encryption keys and other login methods.[01]
Master Password + account salt
↓ KDF (PBKDF2 or Argon2id)
Master Key
↓ HKDF (expand key material for distinct purposes)
Stretched Master Key
+ Protected Symmetric Key stored on the server
↓ Unlock locally
User Symmetric Key
↓ Unlock vault-item keys and ciphertext
Vault plaintext (used only when needed on authorized devices)
Distinguish login authentication from vault decryption: login typically also uses a derived hash that the server can verify, plus MFA; decryption obtains the actual symmetric key. Changing the master password, adjusting KDF parameters and rotating the vault encryption key are different operations. A password change does not instantly invalidate old ciphertext that an attacker has already saved.[22]
02 · PBKDF2 and Argon2id: salt, iterations and memory cost
KDF takes a human-memorable master password that may have insufficient entropy. Salt and expensive computation make the attacker pay again for every guess. Salt usually does not need to be secret; its purpose is to make the same password produce different outputs for different accounts and make precomputed tables harder to reuse.
PBKDF2-HMAC-SHA256(P, salt, c, dkLen) P = master password salt = non-secret salt c = iteration count dkLen = required derived-key length Argon2id(P, salt, m, t, p) m = memory cost t = time / iteration cost p = parallelism
Reference defaults in Bitwarden's documentation: PBKDF2-HMAC-SHA256: 600,000 iterations; Argon2id: 32 MiB, 6 iterations, parallelism 4. PBKDF2 mainly increases repeated computation; Argon2id also requires memory, making highly parallel guessing more expensive. 600,000 cannot be compared directly with 6, because the work models are entirely different.[02]
A simplified cost model is: total guessing time ≈ number of guesses × cost per guess ÷ effective parallelism. GPUs, memory bandwidth, KDF parameters and hardware configuration can change the result substantially, so unlock time cannot be converted directly into a reliable cracking-time estimate. A long, unique master password remains the first line of defense.
03 · AES-CBC/HMAC and AES-GCM: not a contest of bigger numbers
“AES-256” describes the key length, not the security of the entire encryption protocol. Besides encrypting the data, you also need integrity verification; otherwise, an attacker may modify ciphertext without reliable detection.
- Bitwarden: AES-256-CBC + HMAC-SHA256. CBC provides confidentiality; HMAC additionally verifies ciphertext integrity. Security also depends on correct IV handling, key separation and verification order.
- 1Password: AES-256-GCM. GCM is an AEAD mode that integrates encryption and authentication. It likewise requires careful nonce/IV management; a nonce must not be reused where uniqueness is required.
The names CBC and GCM alone do not tell you which overall product is safer. Endpoints, key management and incident recovery often matter just as much.[03][05]
04 · The TOTP formula: HMAC, time windows and dynamic truncation
TOTP is based on HOTP. The website and authenticator share a random
secret seed K, map the current time to a counter
T, then turn the HMAC result into a short number.[11]
T = floor((UnixTime − T₀) / X) H = HMAC(K, encode_8_byte_big_endian(T)) OTP = DynamicTruncate(H) mod 10^d K = shared secret seed T₀ = reference time (commonly the Unix epoch) X = seconds per time step (commonly 30) d = number of output digits (commonly 6)
RFC 6238 supports HMAC-SHA-1, SHA-256 and SHA-512 variants. The
actual service's seed, digit count and time step must be
compatible. A six-digit code has only
10^6 possibilities, so the server needs rate limits for
failed attempts, clock-skew handling and replay checks. Unlimited
guesses within a 30-second window are not acceptable.
A QR code often contains the secret seed or a configuration URI from which it can be recovered. Do not share it in a group as if it were an ordinary login QR code. Anyone who obtains K can calculate codes for future time windows.
05 · Which fields does WebAuthn verification actually check?
During registration, the authenticator creates a key pair for a particular RP, and the website stores the Public Key and Credential ID. During authentication, the website sends an unpredictable Challenge; the browser/authenticator produces an Assertion, which the server verifies.[13]
Registration:
Authenticator → (private key, public key)
Server ← public key + credential ID
Authentication:
Server → challenge
Authenticator → signature over
authenticatorData || SHA256(clientDataJSON)
Server checks:
challenge / type / Origin
rpIdHash / UP・UV flags (according to policy)
signature / credential binding
Origin identifies the website origin invoking the WebAuthn API; RP ID defines the relying-party scope in which the credential may be used. A fake site cannot arbitrarily impersonate the real site's RP ID or obtain a valid assertion for it. The server must check these conditions correctly, rather than verifying the signature and ignoring the context.
“Phishing-resistant” does not mean “prevents every account takeover.” Authenticated session cookies, malicious browser extensions and weak recovery flows can still provide other entry points.[12]
06 · What is a passkey? Synced versus device-bound credentials
A passkey is a way to sign in using FIDO credentials. A fingerprint, face scan or device PIN usually unlocks the authenticator locally; it does not send your biometric data to the website.
- Device-bound: the credential is bound to a specific authenticator or device. Hardware isolation is generally more explicit, but you need a backup key.
- Synced Passkey: the credential can be used across devices through a provider-protected sync system. Recovery is more convenient, but the sync account and devices need particular protection.
You cannot assume that every passkey has a private key that can never be exported. Signing in to a password manager and unlocking its vault may also use different mechanisms. Some designs, for example, need WebAuthn PRF support to derive vault-decryption material from a passkey.[01][13]
07 · 1Password Secret Key, SRP and the key threat model
1Password generates a Secret Key on the device with approximately 128 bits of entropy. Together with the Account Password, it helps protect account encryption keys. It is not an account serial number or a second password to memorize; the Secret Key is kept on authorized devices and in an appropriate Emergency Kit.[04]
SRP（Secure Remote Password） is used for login authentication, not vault data encryption. Its goal is to let the server verify a password proof without receiving the user's original Account Password.[19]
When an attacker obtains only encrypted server-side data, the missing Secret Key is an additional obstacle to offline attack. But if the attacker also controls an authorized device or obtains the Secret Key or recovery materials, the conclusions for a server-only breach no longer apply unchanged.
08 · Autofill: URI matching, iframes and endpoint risk
Bitwarden's Base domain uses the effective registrable domain; Host restricts the hostname; Exact requires the entire URI to match. Host or Exact can be appropriate for sensitive subdomains, but Exact may stop matching when a path or query string changes. OS APIs may also limit the information available for matching on Android and iOS.[18]
Bitwarden disables Autofill on page load by default. Its official documentation warns that compromised websites may exploit this convenience. Manual triggering, checking the address and avoiding suspicious iframes are useful, but once credentials are filled into a malicious page's fields, URL matching alone cannot prevent the page's scripts from reading them.[09]
A clipboard-clear timer only reduces how long data remains there; it is not a security sandbox that prevents all clipboard access.
09 · Vault backup and recovery: encrypted JSON, attachments and deadlocks
Cross-device synchronization mainly keeps current data consistent. It does not necessarily let you retrieve old data after account lockout or loss of every device. In Bitwarden, Password protected encrypted JSON uses a separate password and can be imported into another account; Account restricted depends on the original account's encryption key and should not be your sole cross-account disaster-recovery option.[16]
A regular encrypted JSON export does not include file attachments. A ZIP export containing attachments should be protected separately with an encrypted container; a ZIP extension does not mean that the file is encrypted. Recovery materials must remain accessible even when you cannot log in to the vault.
A simple practical drill is to confirm that you can find your offline recovery codes, decrypt the backup, import it in a test environment and check attachments separately. Use an isolated environment where appropriate; do not enter your real master password on a shared computer just to run a test.
↗ /References
Official documentation, standards and incident reports. Product features and setting names depend on the actual version in use.
[01] Bitwarden · Security Whitepaper — Vault key hierarchy
[02] Bitwarden · Encryption Key Derivation — PBKDF2 / Argon2id
[03] Bitwarden · Encryption Protocols — AES-CBC / HMAC
[04] 1Password · About your Secret Key
[05] 1Password · Security model
[06] Twilio · Authy backups & sync
[07] Twilio · Authy Multi-Device
[08] Twilio · Authy Desktop EOL — 2024-03-19
[09] Bitwarden · Autofill from browser extensions
[10] Android Developers · Secure Clipboard Handling
[12] NIST · SP 800-63B-4
[13] W3C · Web Authentication Level 3
[14] Google Chrome Help · Use saved passwords in other apps
[15] LastPass · Security incident update — Follow-up on the 2022 incident
[16] Bitwarden · Export Vault Data
[17] Apple Developer · UIPasteControl — iOS clipboard-access prompts
[18] Bitwarden · Form URIs for Autofill — Base domain／Host／Exact
[19] 1Password · Secure Remote Password — SRP login authentication
[20] Bitwarden · Authenticator — Local TOTP versus vault synchronization
[21] Yubico · Authenticator — Hardware TOTP versus FIDO2
[22] Bitwarden · Encryption Key Rotation — Master-password changes versus key rotation
[Further reading] iThome Ironman · Cryptography series
This article summarizes product selection and principles. Its diagrams are simplified risk models, not evidence of a completed security audit of any product.Back to top ↑