Two-Factor Authentication Is Not What You Think

Most people believe they understand 2FA. You have a password. You have an app that generates a six-digit code. Two things. Two factors. You are protected.

They are not entirely wrong. But they are right about the mechanics and wrong about what those mechanics actually guarantee.

The original idea behind multi-factor authentication was elegant. Security researchers observed that any single secret can leak. Passwords get stolen. Databases get breached. So they proposed combining secrets from fundamentally different categories: something you know, something you have, something you are. The key insight was not the number of steps — it was orthogonality. A thief who steals your password from a server breach still cannot log in because they do not physically possess your phone. The factors are independent. Compromise one, and the other remains intact.

That independence is the whole point. Strip it away, and you don’t have 2FA. You have 2SV — Two-Step Verification — which sounds nearly identical and is almost entirely different.

The 1Password Problem (And Why It’s More Nuanced Than It Appears)

Millions of people store both their passwords and their TOTP codes inside 1Password. This feels safe. 1Password is encrypted. It has a great reputation. But think about what you have actually done. You have placed “something you know” and “something you have” inside the same encrypted container. If that container is opened, an attacker gets both simultaneously.

Except the picture is more precise than that. 1Password uses a two-ingredient encryption model. Your Master Password is combined with your Secret Key — a 128-bit, locally generated, 34-character string that never leaves your devices and is never transmitted to 1Password’s servers. An attacker who successfully breaches 1Password’s infrastructure and exfiltrates your encrypted vault still cannot decrypt it without the Secret Key, which physically resides on your enrolled device. The device is the “something you have."[1][2]

So the correct characterization is: against a remote attacker, storing TOTP in 1Password preserves a partial “something you have” quality, because they need both your Master Password and physical access to an enrolled device. Against a local attacker who already has your unlocked device, both factors collapse into one. Calling it full 2FA is still wrong, but calling it completely equivalent to one factor misses the architecture.

The Shared Biometrics Trap

Now suppose you rely on Face ID to unlock your 1Password vault. Biometrics are “something you are” — the hardest factor to steal. Surely this improves things?

Then someone registers a second face on your iPhone via Alternate Appearance.

Here is where an easy misunderstanding leads to the wrong threat model. iOS binds biometric authentication to the current enrollment state using the Secure Enclave. When a new face or fingerprint is added, the enrollment state changes, and any application using proper biometric APIs — like 1Password — detects this cryptographic state change and invalidates the existing session token. The vault does not simply open for the new face. The user is forced to fall back to the Master Password and explicitly re-authorize before the new biometric is trusted.[3]

The danger is not that the door is left open. The danger is what happens when you close it again. When you type your Master Password after a biometric state change, you are not just proving identity. You are instructing iOS to cryptographically re-wrap your vault’s decryption keys using the new Secure Enclave state — a state that now includes the additional face. The threat is not physical observation; they do not need to be in the room while you type. The threat is that by authenticating once on that device after they alter the biometric profile, you permanently enroll their face as a valid cryptographic decryption key. The re-wrapping is the attack, not the shoulder-surfing.

The Bigger Failure: TOTP Can Be Stolen in Real Time

Here is the argument the 2FA marketing never makes: both your password and your TOTP code can be captured simultaneously by a sophisticated attacker without ever touching your vault or your device.

Adversary-in-the-Middle (AiTM) phishing proxies — tools like Evilginx2 — sit between you and a legitimate site, relaying your credentials in real time. You land on a convincing clone of your bank. You type your password. The proxy forwards it to the real site. The real site sends a 2FA prompt. You enter your TOTP. The proxy captures it, forwards it to the real site, and completes authentication — all before your six-digit code expires. You see a login error. The attacker has an active session.[4]

In this scenario, having your TOTP in a separate app provided exactly zero additional protection. Both factors were stolen in the same phishing interaction.

Ironically, storing TOTP in a password manager partially defends against this attack for a different reason. Password managers bind autofill to a verified URI. If you land on your-bank-phish.com, the manager refuses to fill credentials registered for your-bank.com. The domain mismatch breaks the autofill chain, making the attack dependent on manual user entry rather than seamless credential injection. A standalone TOTP app has no such binding — it will display the code for any site, at any time, requiring you to manually type it into whatever form is in front of you.[5]

The Actual Standard: Phishing Resistance

This is why the security industry has begun treating phishing resistance — not factor count — as the primary metric of authentication quality. NIST SP 800-63B formalizes this in its Authenticator Assurance Levels (AAL). At AAL2, phishing-resistant authentication is recommended. At AAL3, it is required — and must be backed by a non-exportable hardware key.[6][7]

Password-plus-TOTP, regardless of how they are stored, fails the phishing resistance test. It is AAL1 or AAL2 at best, with known interception vulnerabilities.

FIDO2 and WebAuthn solve this through cryptographic origin binding. During registration, a unique public/private key pair is generated for a specific origin — bank.com, for example. The private key never leaves your hardware. During login, the authenticator signs a challenge that includes the exact origin making the request. A phishing site at bank-secure-login.com cannot generate a valid challenge for bank.com. The signature would fail verification at the legitimate server, and the attack chain breaks — not because the user recognized the fake site, but because the cryptography made impersonation mathematically invalid.[8][9][4]

This is categorically different from TOTP. TOTP is a shared secret that produces valid codes regardless of which domain is asking for them. FIDO2 credentials are domain-locked by design.

The Missing Tier: Synced Passkeys

Before defining a practical architecture, there is a significant shift in the current authentication landscape that most essays on this topic miss entirely: Passkeys.

Passkeys are multi-device FIDO credentials. When you save a Passkey to 1Password, Apple Keychain, or Google Password Manager, you get the exact same cryptographic origin binding as a hardware YubiKey. There is no shared secret. There is no TOTP code to intercept. The private key is generated on-device and never transmitted. A phishing site cannot harvest it because the origin binding makes it cryptographically meaningless outside the registered domain.[9][8]

The trade-off is one property: exportability. A hardware security key stores a key that can never leave the physical device — this is what NIST calls non-exportable and what qualifies for AAL3. A synced Passkey in 1Password can propagate across your enrolled devices, which means a compromised vault could theoretically expose the credential. For most accounts, this is an acceptable trade-off. For root identities — your email, your SSO provider — it is not.[10]

The result is a three-layer spectrum, not a binary choice:

Authentication Method	Phishing Resistant	Shared Secret	Portable	Best For
Password + TOTP	✗	✓ (interceptable)	✓	Low-value services
Passkey (synced)	✓	✗	✓ (via vault)	Tier 1 (General SaaS)
Hardware FIDO2 Key	✓	✗	✗ (non-exportable)	Tier 0 (Identity Roots)

Passkeys do not replace hardware keys. They bridge the gap between vulnerable TOTP and the cost and friction of carrying a physical key. They bring AAL2-level phishing resistance into the software vault, which is a profound improvement over the current default of storing TOTP codes alongside passwords.

Practical Architecture

The hierarchy that emerges from this analysis is now three-tiered:

Tier 0 — Identity Roots (Email, 1Password Account, SSO): Use hardware FIDO2 keys. For 1Password specifically, the hardware key acts as a second factor in addition to the existing Secret Key and Master Password architecture — not a replacement for it. The Master Password and Secret Key protect your vault contents at rest. The hardware key protects the login to your 1Password account itself, preventing an attacker from adding a new trusted device and extracting your Secret Key remotely. Stack these layers intentionally; they address different attack surfaces.

Tier 1 — General SaaS, Financial, Work Accounts: Migrate to Passkeys wherever the service supports them. You gain cryptographic origin binding and eliminate the shared TOTP secret entirely, at the cost of portability within your vault. For services that do not yet support Passkeys, TOTP in 1Password is acceptable — the Secret Key architecture provides remote compromise resistance, and URI binding provides partial phishing protection.

Tier 2 — Low-Value Services (Forums, Media, Newsletters): TOTP in 1Password, or password-only with a unique generated password per site. The residual risk is proportional to the account’s blast radius, which here is minimal.

What This Changes

The industry treats “enable 2FA” as a completed security upgrade. NIST SP 800-63B treats it as a floor, not a ceiling. The actual ceiling — authentication that cannot be phished, replayed, or captured in transit — requires cryptographic origin binding, not a second one-time code.[7]

TOTP was a meaningful improvement over passwords alone. But it was designed in 2005, before AiTM tooling was packaged and sold on criminal forums, and before Passkeys made origin-bound authentication available to ordinary users without buying hardware. Calling TOTP-based authentication “2FA” today is technically accurate by older definitions and practically misleading given current attack sophistication and available alternatives.

The question is never “do I have 2FA?” The right questions are: can this be phished? Can both factors be captured simultaneously? If my device is compromised, does the architecture preserve independent factors? Is origin binding enforced cryptographically, or does it rely on users noticing a suspicious domain?

When you ask those questions, you stop counting steps and start thinking about assurance levels, origin binding, vault architecture, and failure modes. That is the shift from checking a compliance checkbox to actually understanding what protects you — and what does not.

The 1Password Problem (And Why It’s More Nuanced Than It Appears)#

The Shared Biometrics Trap#

The Bigger Failure: TOTP Can Be Stolen in Real Time#

The Actual Standard: Phishing Resistance#

The Missing Tier: Synced Passkeys#

Practical Architecture#

What This Changes#

Sources#