Authentication Factors and MFA

Authentication Factors and MFA: Core Concepts

A password alone is a single point of failure. If an attacker steals it — through phishing, a data breach, a keylogger, or brute force — they own the account. Multi-factor authentication (MFA) mitigates this by requiring two or more independent factors: something you know, something you have, or something you are. An attacker who steals your password still cannot authenticate without the second factor.

The Three Factor Categories

Knowledge factors (something you know) — Information the user can recall:

• Passwords and PINs
• Security questions (mother's maiden name, first pet)
• Patterns or gestures

Passwords are the most common knowledge factor, but they are also the weakest. Users reuse passwords across sites, choose predictable patterns, and fall for phishing. Security questions are even worse — answers are often publicly discoverable through social media.

Possession factors (something you have) — Physical objects the user controls:

• Hardware security keys (YubiKey, Titan Key)
• Smartphones running authenticator apps (TOTP)
• Smart cards and USB tokens
• One-time passwords sent via SMS or email

Possession factors are significantly stronger than knowledge factors because an attacker must physically possess the device. However, they can be lost, stolen, or duplicated (in the case of SMS).

Inherence factors (something you are) — Biometric characteristics:

• Fingerprint recognition
• Facial recognition
• Iris or retina scanning
• Voice recognition
• Behavioral biometrics (typing rhythm, mouse movement)

Biometrics are convenient but have limitations: they cannot be changed if compromised (you cannot replace your fingerprint), they have false acceptance and false rejection rates, and they can be spoofed with high-quality replicas.

How MFA Combines Factors

MFA requires factors from at least two different categories. Common combinations:

Using two factors from the same category (e.g., password + security question) is not true MFA — it is two-step verification within a single factor category.

TOTP: Time-Based One-Time Passwords

TOTP (RFC 6238) is the most common software-based MFA method. Both the server and the authenticator app share a secret key. Every 30 seconds, both compute a 6-digit code using HMAC-SHA1 of the current time step:

TOTP = HMAC-SHA1(secret_key, current_time / 30) mod 1,000,000

The code changes every 30 seconds, so even if an attacker intercepts a code, it expires quickly. Google Authenticator, Authy, and 1Password all implement TOTP.

FIDO2/WebAuthn: Phishing-Resistant MFA

FIDO2 is the current gold standard for phishing-resistant authentication. It uses public key cryptography:

1. During registration, the authenticator generates a key pair and sends the public key to the server
2. During authentication, the server sends a challenge
3. The authenticator signs the challenge with the private key (which never leaves the device)
4. The server verifies the signature with the public key

Because the private key is bound to the origin (domain name), a phishing site cannot use a credential stolen from the real site. The browser will not send the credential to a different domain.

Where It Fits

MFA is the most effective single control against credential-based attacks. It works alongside authorization (what you can do after authentication) and account recovery (how you regain access if you lose your factors). Study the TLS Handshake first to understand how authentication factors are protected in transit, then move to Authorization Models to understand what happens after authentication.

Authentication Factors and MFA: Practice

MFA is easy to deploy but hard to deploy well. The exercises below cover the most common implementations and their pitfalls.

Exercise 1: Set Up TOTP with Python

import hmac
import hashlib
import struct
import time
import base64

def generate_totp(secret: str, time_step: int = 30, digits: int = 6) -> str:
    """Generate a TOTP code from a base32-encoded secret."""
    key = base64.b32decode(secret.upper())
    counter = int(time.time() // time_step)
    
    # Pack counter as 8-byte big-endian
    counter_bytes = struct.pack('>Q', counter)
    
    # HMAC-SHA1
    h = hmac.new(key, counter_bytes, hashlib.sha1).digest()
    
    # Dynamic truncation
    offset = h[-1] & 0x0F
    code = struct.unpack('>I', h[offset:offset+4])[0] & 0x7FFFFFFF
    
    return str(code % (10 ** digits)).zfill(digits)

# Example usage
secret = "JBSWY3DPEHPK3PXP"  # Base32-encoded secret
print(f"Current TOTP: {generate_totp(secret)}")

This is the same algorithm used by Google Authenticator. The secret is shared between the server and the authenticator app during initial setup (usually by scanning a QR code).

Exercise 2: Evaluate MFA Methods for Phishing Resistance

Rank these MFA methods from most to least phishing-resistant:

1. FIDO2/WebAuthn hardware key — Phishing-resistant (origin-bound), cannot be intercepted
2. TOTP authenticator app — Codes can be phished if user enters them on a fake site, but codes expire in 30 seconds
3. Push notification — Vulnerable to push fatigue attacks (attacker triggers many pushes until user approves)
4. SMS codes — Vulnerable to SIM swapping, SS7 interception, and phishing
5. Email codes — Vulnerable to email account compromise and phishing

Exercise 3: Implement MFA Bypass Prevention

A common attack is to bypass MFA by calling the help desk and social engineering a password reset. Implement these controls:

# Require MFA re-authentication for sensitive operations
def require_step_up_auth(user, operation):
    sensitive_operations = ['change_password', 'add_mfa_device', 'transfer_funds']
    
    if operation in sensitive_operations:
        # Require fresh MFA verification, not just a valid session
        if not user.recently_authenticated_with_mfa(max_age=300):
            return require_mfa_challenge(user)
    
    return allow_operation(user, operation)

# Prevent MFA device enumeration
def add_mfa_device(user, device_info):
    # Require existing MFA verification before adding a new device
    if not user.has_mfa_device():
        # First device: require identity verification through a different channel
        require_in_person_verification(user)
    else:
        # Additional devices: require existing MFA
        require_mfa_challenge(user)

Exercise 4: Handle MFA Recovery Securely

When a user loses their MFA device, you need a recovery mechanism that does not become a backdoor:

def initiate_account_recovery(user):
    # Generate a single-use recovery code
    recovery_code = secrets.token_urlsafe(32)
    
    # Store hashed, not plaintext
    user.recovery_code_hash = hashlib.sha256(recovery_code.encode()).hexdigest()
    user.recovery_code_expires = datetime.now() + timedelta(hours=24)
    
    # Send through a different channel than the one being recovered
    if user.mfa_method == 'sms':
        send_recovery_code_via_email(user.email, recovery_code)
    else:
        send_recovery_code_via_sms(user.phone, recovery_code)
    
    # Require identity verification before allowing password reset
    require_identity_verification(user)

Check Your Understanding

• Why is password + security question not considered true MFA?
• What makes FIDO2 more phishing-resistant than TOTP?
• What is push fatigue and how does it undermine MFA?

Authentication Factors and MFA: Trade-offs and Interviews

MFA significantly improves security, but it is not without trade-offs. Understanding these trade-offs is essential for choosing the right MFA strategy for your organization.

When MFA Is the Wrong Tool

• Shared accounts: MFA requires a personal device or credential. For shared accounts (e.g., a team admin account), MFA is difficult to implement. Use a password manager with shared vaults instead, and audit access.
• Emergency access: In life-safety situations (e.g., hospital systems), requiring MFA can delay critical access. Implement break-glass accounts with strong monitoring and automatic alerting.
• Low-risk internal tools: For internal tools with no sensitive data, the overhead of MFA may not be justified. Risk-based authentication (require MFA only for unusual access patterns) is a better approach.
• Users without smartphones: Hardware keys or smart cards are alternatives, but they add cost and logistics. For user populations without smartphones, consider TOTP on a dedicated device or SMS as a fallback.

The Usability vs. Security Trade-off

Every MFA method introduces friction:

The best MFA method is the one users will actually use. If users find TOTP too cumbersome, they will find workarounds that undermine security.

Common MFA Attacks

• Phishing: Attacker creates a fake login page that proxies credentials and MFA codes in real-time. Mitigated by FIDO2 (origin-bound).
• SIM swapping: Attacker convinces a mobile carrier to transfer the victim's phone number to a new SIM. Mitigated by avoiding SMS.
• Push fatigue: Attacker triggers repeated push notifications until the victim approves out of frustration. Mitigated by number matching (user must type a number shown on the login screen).
• MFA fatigue + help desk social engineering: Attacker triggers MFA pushes and then calls the help desk claiming to be the victim. Mitigated by strict identity verification for help desk interactions.
• Token theft: Malware steals session tokens or TOTP secrets from the device. Mitigated by hardware keys (private key never leaves the device).

How This Comes Up in Interviews

• "What is the strongest MFA method and why?" FIDO2/WebAuthn hardware keys. They are phishing-resistant (origin-bound), the private key never leaves the device, and they cannot be intercepted or replayed.
• "Why is SMS-based MFA considered weak?" SMS is vulnerable to SIM swapping (attacker ports the victim's number), SS7 interception (attacker intercepts SMS on the signaling network), and phishing (victim enters the code on a fake site).
• "How do you handle MFA for users who lose their device?" Provide recovery codes at enrollment time (stored securely by the user). For account recovery, verify identity through an alternative channel and require a waiting period to prevent real-time social engineering.