The Three Factor Categories
Authentication factors fall into three categories: something you know (a password or PIN), something you have (a phone, hardware key, or smart card), and something you are (a fingerprint or face scan). True multi-factor authentication combines factors from at least two different categories — a password plus a security question is not MFA, because both are 'something you know.' OWASP and NIST SP 800-63B both emphasize that combining independent factor categories is what defeats an attacker who has compromised just one, since stealing a password doesn't also grant physical possession of a hardware key or biometric data.
Cricket analogy: It's like a stadium's VIP box requiring both a printed ticket (something you have) and a signature match against ID (something you are/know) — a forged ticket alone, or a guessed name alone, isn't enough to get past both checks.
TOTP, SMS, and Push Notifications
Time-based One-Time Password (TOTP), defined in RFC 6238, generates a 6-digit code from a shared secret and the current Unix time, refreshed every 30 seconds — apps like Google Authenticator and Authy implement this standard, and it works entirely offline once the secret is provisioned via QR code. SMS-based MFA is widely deployed but NIST SP 800-63B has deprecated it as a 'restricted' authenticator because SMS is vulnerable to SIM-swapping attacks, where a social-engineered carrier employee ports a victim's number to an attacker's SIM. Push notifications (approve/deny prompts sent to a registered app) improve usability over TOTP but introduced a new risk called 'MFA fatigue' or 'prompt bombing,' where attackers spam approval requests hoping the victim eventually taps 'approve' out of annoyance or confusion — mitigated by requiring number-matching (the app shows a number the user must enter on the login screen) rather than a simple approve/deny button.
Cricket analogy: TOTP is like a physical stopwatch-synced signal flare system between the scorers and the third umpire that changes every 30 seconds — SMS OTP is like relaying that signal through a courier who could be intercepted (SIM swap) before delivery.
# Python: generating and verifying a TOTP code (RFC 6238) using pyotp
import pyotp
# Provisioning: generate a secret and enrollment URI for the user's authenticator app
secret = pyotp.random_base32()
totp = pyotp.TOTP(secret)
provisioning_uri = totp.provisioning_uri(
name="alice@example.com",
issuer_name="SkillVeris"
) # encode this as a QR code for the user to scan
# Verification: during login, check the code the user typed
user_submitted_code = "123456"
if totp.verify(user_submitted_code, valid_window=1): # allow 1 step (30s) of clock drift
print("MFA verified")
else:
print("Invalid or expired code")NIST SP 800-63B classifies SMS/voice as a 'restricted' authenticator, not fully deprecated, but agencies and security-conscious platforms are encouraged to migrate users toward app-based TOTP, push with number-matching, or FIDO2 hardware keys wherever possible.
WebAuthn and FIDO2 Hardware Keys
WebAuthn, standardized by the W3C and FIDO Alliance, replaces shared secrets entirely with public-key cryptography: during registration, the authenticator (a YubiKey, or a platform authenticator like Touch ID) generates a key pair, keeps the private key on-device (never transmitted), and sends the public key to the server. During login, the server sends a random challenge that the authenticator signs with the private key, proving possession without ever exposing a secret that could be phished, replayed, or database-leaked. This makes WebAuthn phishing-resistant in a way TOTP is not — a fake login page can still trick a user into typing a TOTP code into it (real-time phishing/relay), but it cannot extract or replay a WebAuthn signature because the challenge is bound to the origin domain.
Cricket analogy: It's like a player's identity being verified by a unique, non-copyable action — bowling a specific documented action recognized biomechanically by the ICC — rather than a memorized password that could be stolen and repeated by an impostor.
OWASP's Multifactor Authentication Cheat Sheet recommends offering users a choice of MFA methods where possible, with FIDO2/WebAuthn as the strongest phishing-resistant option, TOTP as a solid fallback, and SMS reserved as a last resort for users without smartphone access.
- True MFA combines factors from at least two of: something you know, something you have, something you are.
- TOTP (RFC 6238) generates time-synced 6-digit codes offline from a shared secret.
- SMS-based MFA is vulnerable to SIM-swapping and is classified as 'restricted' by NIST SP 800-63B.
- Push notifications improve usability but are vulnerable to 'MFA fatigue' / prompt-bombing attacks.
- Number-matching in push MFA mitigates prompt bombing by requiring active user input, not just a tap.
- WebAuthn/FIDO2 uses public-key cryptography bound to the origin domain, making it phishing-resistant.
- OWASP recommends offering a choice of MFA methods, prioritizing WebAuthn, then TOTP, with SMS as a last resort.
Practice what you learned
1. Why is a password combined with a security question not considered true multi-factor authentication?
2. What vulnerability has led NIST to classify SMS-based MFA as a 'restricted' authenticator?
3. What is 'MFA fatigue' or 'prompt bombing'?
4. Why is WebAuthn considered phishing-resistant in a way TOTP is not?
Was this page helpful?
You May Also Like
Broken Authentication Risks
Understand how authentication mechanisms fail in practice — from credential stuffing to weak session handling — and how OWASP frames these risks.
Secure Password Storage
Learn why passwords must never be stored in plaintext or reversible form, and how modern hashing algorithms like bcrypt and Argon2 protect credentials at rest.
OAuth and OIDC Security Basics
Learn the difference between OAuth 2.0 (authorization) and OpenID Connect (authentication), and the common misconfigurations that lead to token theft and account takeover.