Authentication factors vary greatly in security strength
Aliases: authenticator assurance · phishing-resistant authentication · MFA strength
What it is
Threat-dependent authenticator strength means that a “second factor” is not one security grade. SMS, voice, manually entered OTPs, approval pushes, hardware keys, and verifier-bound cryptographic authenticators resist real-time phishing, number transfer, device theft, malware, prompt bombing, and verifier compromise differently. A single “2FA enabled” label conceals these differences.
Why it happens
Attackers target transferable information and weak channels in the protocol. A code that a person can read and retype can usually be relayed through a fake page; a context-free approval push can be accepted after repeated annoyance. Binding a cryptographic response to the correct verifier reduces relay, but protection still depends on key storage, device activation, binding, and recovery. Factor count describes structure, not a complete threat model.
Studying it
List assets, attacker capabilities, and the authentication sequence before testing each offered authenticator at protocol and human levels. An authorized red team can simulate proxy phishing, number-transfer indicators, a stolen locked device, push bombing, and malicious recovery. Measure transferability, transaction recognition, attack success, and false rejection, not login time alone. Never trick real users into surrendering production credentials.
Where it stops holding
A weaker second factor can still improve on password-only access in lower-risk or constrained settings and may serve as a migration or coverage channel. “Phishing-resistant” does not mean resistant to every attack: an unlocked endpoint, stolen session, malicious application, or flawed recovery may bypass it. Allowed authenticators should reflect account impact, accessibility, device ecosystem, and applicable standards rather than one universal ranking.
Applying it
- Record the threats each authenticator does and does not resist, not merely that it adds a factor.
- For high-impact actions, prioritize verifier-bound cryptographic authenticators while maintaining risk-controlled, reachable alternatives.
- Show initiating device, location, or transaction context in approvals and rate-limit prompts; avoid authentication by a context-free “Allow” button.
- Explain differences with consequences such as “resists live phishing,” “depends on the phone network,” and “requires a physical device,” then monitor downgrade and bypass paths.