Scrolls
3 min read
On this page

Multi-Factor Authentication

Authentication Factors

Authentication factors are independent categories of evidence that verify a user's identity. True multi-factor authentication requires factors from at least two different categories.

Something you know:
  - Password, PIN, security questions
  - Can be guessed, phished, or leaked in breaches
  - Weakest factor when used alone

Something you have:
  - Phone (TOTP app, SMS), hardware security key, smart card
  - Must be physically possessed by the attacker
  - Lost or stolen devices are the primary risk

Something you are:
  - Fingerprint, face recognition, iris scan, voice print
  - Cannot be forgotten or lost
  - Cannot be changed if compromised (you only have one face)
  - Privacy concerns with biometric data storage

Multi-factor means combining categories:
  Password + TOTP code       = two factors (know + have)
  Password + fingerprint     = two factors (know + are)
  Password + security question = one factor (know + know)
  Fingerprint + face scan    = one factor (are + are)

Two things from the same category are NOT multi-factor.

TOTP: Time-Based One-Time Passwords

TOTP is the most widely deployed MFA method. It generates a 6-8 digit code that changes every 30 seconds, based on a shared secret and the current time.

How TOTP Works

Setup:
1. Server generates a random secret key (160 bits minimum)
2. Server encodes it as a QR code (otpauth:// URI)
3. User scans QR code with authenticator app
4. Both server and app now share the same secret

Authentication:
1. App computes: HMAC-SHA1(secret, floor(unix_time / 30))
2. Extracts 6 digits from the HMAC result
3. User enters the 6-digit code
4. Server performs the same computation and compares

The server typically accepts codes for the current period
plus one period before and after (to handle clock drift).

TOTP URI format (encoded in QR code):
  otpauth://totp/App:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=App&algorithm=SHA1&digits=6&period=30

TOTP in Practice

Popular authenticator apps:
  - Google Authenticator
  - Microsoft Authenticator
  - Authy (with cloud backup — debated security trade-off)
  - 1Password, Bitwarden (integrated with password managers)

Implementation considerations:
  - Store the TOTP secret encrypted, not in plaintext
  - Provide recovery codes during setup (one-time use backup codes)
  - Allow users to verify a code before enabling TOTP
  - Show the secret as text alongside the QR code (accessibility)
  - Implement rate limiting on TOTP verification
  - Track used codes to prevent replay within the validity window

TOTP Limitations

TOTP is phishable:
  1. Attacker sets up a fake login page
  2. User enters password AND TOTP code on the fake page
  3. Attacker immediately relays both to the real site
  4. Attacker gets authenticated before the TOTP code expires

This is a real-time phishing (relay) attack. It requires
active attacker involvement but is well-documented and
used in targeted attacks.

TOTP also requires:
  - User to have their phone available
  - Clock synchronization between device and server
  - Manual code entry (friction for users)

WebAuthn & Passkeys

WebAuthn (Web Authentication) is a W3C standard that provides phishing-resistant authentication using public-key cryptography. Passkeys are the user-facing implementation of WebAuthn.

How WebAuthn Works

Registration:
1. Server sends a challenge (random bytes)
2. Browser/device creates a key pair (public + private)
3. Private key is stored securely on the device (TPM, Secure Enclave)
4. Public key is sent to the server
5. Server stores the public key associated with the user

Authentication:
1. Server sends a challenge (random bytes) with the credential ID
2. Browser/device signs the challenge with the private key
3. Signature is sent to the server
4. Server verifies the signature with the stored public key

The private key never leaves the device.

Why WebAuthn is Phishing-Resistant

The key property: origin binding.

When authenticating, the browser includes the origin (domain)
in the signed data. A phishing site at evil-app.com cannot
produce a valid signature for real-app.com because:

1. The browser binds the signature to the current origin
2. The private key is associated with the legitimate origin
3. The phishing site's origin does not match
4. The signature verification fails on the legitimate server

This is not a policy decision — it is cryptographically enforced.
No amount of social engineering can produce a valid signature
for the wrong domain.

Passkeys

Passkeys are the consumer-friendly evolution of WebAuthn.

Platform passkeys:
  - Stored in the device's secure element (iPhone Secure Enclave,
    Android Titan M, Windows TPM)
  - Synced across devices via iCloud Keychain, Google Password Manager
  - Authenticated with device biometrics (Face ID, fingerprint)
  - No codes to enter, no phone to pick up

Cross-device authentication:
  - Scan QR code on phone to authenticate on laptop
  - Uses Bluetooth to verify physical proximity
  - Prevents remote phishing (phone must be physically near the laptop)

Real-world adoption:
  - Google: Passkeys as default sign-in method (2023)
  - Apple: Passkeys integrated into macOS and iOS (2022)
  - Microsoft: Passkey support in Windows Hello
  - GitHub: Passkey support for account authentication (2023)

Real example: Google internal results
- Google required hardware security keys for all employees in 2017
- Result: Zero successful phishing attacks on employee accounts
- Before the requirement, employees were regularly phished
- This is the strongest evidence for phishing-resistant MFA

Hardware Security Keys

Devices: YubiKey, Google Titan Key, SoloKeys, Nitrokey

Advantages:
  - Dedicated hardware, not dependent on phone
  - Phishing-resistant (WebAuthn/FIDO2 protocol)
  - No battery, no Bluetooth, no software updates
  - Works offline (USB or NFC)
  - Durable and long-lasting

Disadvantages:
  - Physical cost ($25-70 per key)
  - Users need a backup key (loss or damage)
  - Not all applications support hardware keys
  - USB-A vs USB-C vs NFC compatibility

Deployment recommendation:
  - Issue two keys per employee (primary and backup)
  - Register both during onboarding
  - Store backup in a secure location
  - Have a recovery process for lost keys

SMS OTP

SMS one-time passwords send a code via text message. They are the most widely deployed MFA method but also the weakest.

How SMS OTP works:
1. User enters username and password
2. Server generates a random code (typically 6 digits)
3. Server sends code via SMS to the user's registered phone number
4. User enters the code
5. Server verifies the code matches and has not expired

Better than no MFA, but vulnerable to several attacks.

SMS Vulnerabilities

SIM swapping:
  1. Attacker calls the victim's carrier
  2. Social-engineers the carrier into transferring the number
     to a SIM the attacker controls
  3. Attacker now receives all SMS messages for that number
  4. Attacker intercepts MFA codes

  Real example: 2019 Twitter CEO Jack Dorsey
  - Attacker SIM-swapped Dorsey's phone number
  - Posted unauthorized tweets from @jack
  - SIM swap was performed by social-engineering AT&T

  Real example: 2022 Lapsus$ attacks
  - Group used SIM swapping to bypass MFA
  - Compromised Microsoft, Nvidia, Samsung, Uber
  - Paid carrier employees for SIM swaps

SS7 interception:
  - SS7 is the protocol used by telecom networks to route calls and SMS
  - Known vulnerabilities allow interception of SMS messages
  - Used by nation-state actors and organized crime
  - No fix available — it is a fundamental protocol weakness

Malware:
  - Mobile malware can read incoming SMS messages
  - Android accessibility services can read notifications
  - Less common but documented in targeted attacks

SMS OTP Guidance

NIST SP 800-63B position:
  - SMS OTP is "RESTRICTED" — acceptable but with caveats
  - Organizations should evaluate the risk of SMS interception
  - Plan migration to phishing-resistant alternatives

When SMS OTP is acceptable:
  - Consumer applications where users will not adopt stronger MFA
  - Low-to-medium risk operations
  - As a step up from password-only (any MFA > no MFA)

When SMS OTP is insufficient:
  - High-value targets (executives, administrators)
  - Financial transactions
  - Government systems
  - Any account with access to sensitive data at scale

When to Require MFA

Not every action needs MFA. Requiring it everywhere causes fatigue. Requiring it nowhere leaves accounts exposed.

Always require MFA:
  - Admin access to any system
  - Access to customer data in bulk
  - Financial transactions above a threshold
  - Changes to account security settings (password, MFA, recovery email)
  - Infrastructure access (SSH, cloud console, CI/CD)
  - Source code repository access

Require MFA on first use, then trust the device:
  - Login from a new device or location
  - Login after extended inactivity
  - Access to sensitive features (export data, invite users)

Optional MFA (user's choice):
  - Consumer accounts with low-risk data
  - Public content management
  - Low-value subscriptions

Step-up authentication:
  - User logs in with password (session created)
  - User accesses sensitive feature (payment, data export)
  - System requires MFA at that point, not at initial login
  - Reduces friction for normal use while protecting sensitive operations

Recovery & Backup

MFA creates a lockout risk. If a user loses their second factor, they lose access. Recovery mechanisms must be secure without undermining MFA.

Recovery codes:
  - Generate 8-10 single-use codes during MFA setup
  - Each code is 8+ characters, cryptographically random
  - Store hashed on the server (like passwords)
  - User stores them securely (password manager, printed and locked away)
  - Each code can only be used once

Recovery process:
  1. User selects "I lost my device"
  2. User enters a recovery code
  3. System authenticates the user
  4. System requires the user to set up a new MFA method immediately
  5. Old MFA method is invalidated
  6. Alert sent to user's email about the MFA change

What NOT to do for recovery:
  - "Call support and verify your identity" with weak verification
  - Allow recovery via email alone (email is not a second factor
    if it is already the primary communication channel)
  - Allow disabling MFA without authentication
  - Accept security questions as recovery (same weakness as for passwords)

Real example: 2022 Uber breach (MFA fatigue)
- Attacker had the employee's password (purchased from a broker)
- Spammed the employee with MFA push notifications
- Employee approved a notification to make them stop
- Attacker gained full access to internal systems

Prevention:
  - Number matching: push notification shows a number,
    user must type that number in the app
  - Require interaction: user must open the app and confirm
  - Limit push attempts: after 3 declined pushes, require
    a different verification method
  - Alert on repeated declined pushes

Common Pitfalls

  • Treating SMS as strong MFA: SMS is better than no MFA but is vulnerable to SIM swapping, SS7 interception, and mobile malware. For high-value accounts, use TOTP or WebAuthn.

  • MFA fatigue attacks: Push notification MFA without number matching allows attackers to spam approvals. Users eventually approve out of frustration. Implement number matching and limit attempts.

  • No backup method: If a user's only MFA method is a single phone, losing that phone means losing access. Always provide recovery codes during setup and encourage registering multiple methods.

  • Storing TOTP secrets in plaintext: The TOTP shared secret is equivalent to a password. If an attacker obtains it, they can generate valid codes. Encrypt TOTP secrets at rest.

  • Not rate-limiting MFA verification: A 6-digit TOTP code has 1,000,000 possible values. At 1,000 attempts per second, an attacker can brute-force it in under 17 minutes. Rate limit to 3-5 attempts per period.

  • Implementing MFA only at login: If an attacker steals a session token, MFA at login does not help. Use step-up authentication for sensitive operations within an authenticated session.

Key Takeaways

  • MFA combines factors from different categories: something you know, something you have, something you are. Two passwords is not MFA.
  • TOTP (Google Authenticator) is widely supported and effective against credential stuffing, but it is phishable via real-time relay attacks.
  • WebAuthn/Passkeys are phishing-resistant by design. The browser cryptographically binds authentication to the correct domain. This is the future of authentication.
  • SMS OTP is the weakest MFA method due to SIM swapping and SS7 vulnerabilities. It is better than nothing but insufficient for high-value accounts.
  • Require MFA for admin access, sensitive data, financial operations, and infrastructure access. Use step-up authentication for sensitive operations within sessions.
  • Always provide recovery codes. MFA without a recovery mechanism turns a lost phone into a lost account.