Authentication - Learning Module

Loading content...

0/240

Multi-Factor Authentication

Beyond the Password Barrier

In 2020, Twitter suffered a spectacular security breach. High-profile accounts—including those of Barack Obama, Joe Biden, Elon Musk, and Apple—were hijacked to promote a cryptocurrency scam. The attackers didn't break encryption or exploit a zero-day vulnerability. They compromised employee accounts through social engineering, bypassing password-only authentication.

This attack, like countless others, underscores a fundamental truth: passwords alone are insufficient. No matter how strong a password is, a single factor of authentication creates a single point of failure. Phishing, credential theft, and social engineering can defeat even the most carefully chosen password.

Multi-Factor Authentication (MFA) addresses this vulnerability by requiring multiple independent proofs of identity. An attacker who compromises a password still cannot authenticate without also possessing a physical device or biometric characteristic. This defense-in-depth approach has become essential for any security-conscious system.

What You Will Learn

By the end of this page, you will understand the theoretical foundations of multi-factor authentication, the major categories of additional factors, how time-based and challenge-based second factors work cryptographically, and the architectural patterns for implementing MFA in operating systems and applications. You'll also understand the security tradeoffs between different MFA approaches.

The Theory of Multiple Factors

Multi-factor authentication requires users to provide evidence from two or more distinct categories of authentication factors. The security improvement comes not from the number of factors, but from their independence—the requirement that compromising one factor provides no advantage in compromising another.

The Three Factor Categories (Revisited):

Recall the three fundamental authentication factor types:

Knowledge Factors (Something you know): Passwords, PINs, security questions
Possession Factors (Something you have): Hardware tokens, smartphones, smart cards
Inherence Factors (Something you are): Fingerprints, facial geometry, voice patterns

True MFA requires factors from different categories. Two passwords (both knowledge factors) provide no additional security category—an attacker who can steal one password can likely steal two. Similarly, a password plus a security question offers only marginal improvement since both are knowledge-based and vulnerable to similar attacks.

Multi-Factor vs. Multi-Step Authentication
Authentication Type	Example	Security Improvement	Vulnerability
Single Factor	Password only	Baseline	Phishing, credential theft, brute force
Multi-Step (Same Category)	Password + security question	Marginal	Both factors vulnerable to same attacks
True MFA (Two Categories)	Password + TOTP code	Significant	Requires compromising two independent systems
Strong MFA (Three Categories)	Password + hardware key + fingerprint	Maximum	Requires physical presence plus knowledge

Independence and Attack Surface:

The security value of MFA depends critically on factor independence. Consider the attack surfaces:

Password can be stolen via: phishing, keyloggers, credential stuffing, brute force
TOTP code requires: access to the seed secret or real-time interception
Hardware token requires: physical possession of the device
Biometric requires: physical presence or sophisticated spoofing

An attacker targeting a password-only system needs to execute one type of attack. An attacker targeting password + hardware token must execute two fundamentally different attacks—often requiring both remote and physical access.

The Probability Model:

If we model each factor's compromise probability independently:

P(password compromised) = P₁
P(second factor compromised) = P₂

For true MFA, the probability of complete compromise is:

P(both compromised) = P₁ × P₂

If a password has a 1% monthly compromise probability and a hardware token has 0.01% probability, the combined system has:

P(both) = 0.01 × 0.0001 = 0.000001 (0.0001%)

This multiplicative effect—rather than additive—explains why even imperfect second factors dramatically improve security.

The Session Cookie Caveat

MFA protects the authentication moment but not necessarily the authenticated session. Session hijacking attacks (stealing cookies after authentication) bypass MFA entirely. Comprehensive security requires session protection, re-authentication for sensitive operations, and anomaly detection alongside MFA.

Possession-Based Factors

Possession factors prove identity by demonstrating control over a physical object or device. Unlike knowledge factors, possession factors cannot be copied remotely—an attacker must physically obtain or compromise the device.

Categories of Possession Factors:

1. Hardware Security Keys: Dedicated cryptographic devices like YubiKey, Titan, and SoloKey. These implement protocols like FIDO2/WebAuthn and provide the strongest possession-based authentication:

Cryptographic operations happen on the device (private keys never leave)
Physical user presence verified through touch or button press
Phishing resistance through origin binding (keys are bound to specific domains)
Malware resistance since the device is independent of the user's computer

2. Smartphones (Authenticator Apps): Applications like Google Authenticator, Microsoft Authenticator, and Authy generate time-based or event-based codes:

Software-based codes generated on user's personal device
Threat model includes device theft, malware on phone, SIM swapping
Phishing vulnerability exists since users manually enter codes

3. SMS-Based OTP: One-time passwords delivered via SMS text message:

Widely available since it requires only a phone number
Significantly weaker than other possession factors
Vulnerable to SIM swapping, SS7 attacks, real-time phishing proxies

4. Smart Cards: Cryptographic cards requiring a reader:

Common in enterprise environments (PIV cards, Common Access Cards)
Require physical infrastructure (card readers at each workstation)
Support PKI operations with certificate-based authentication

Possession Factor Security Hierarchy

•Hardware Security Keys (FIDO2) — Strongest. Cryptographic challenge-response, origin binding prevents phishing, private keys never leave device
•Smart Cards (PIV/PKI) — Very strong. Hardware-protected private keys, certificate-based authentication, requires physical infrastructure
•Authenticator Apps (TOTP/HOTP) — Strong. Shared-secret based, vulnerable to phishing (manual code entry), depends on device security
•Push Notifications — Moderate. Convenient but vulnerable to notification fatigue attacks, requires secure channel to device
•SMS OTP — Weak. Vulnerable to SIM swapping, SS7 attacks, interception at carrier level, real-time phishing

SIM Swapping: SMS's Fatal Flaw:

SMS-based authentication has been deprecated by NIST for sensitive applications due to fundamental vulnerabilities in the telephone network:

Social Engineering Attack: Attacker contacts victim's mobile carrier
Identity Impersonation: Claims to be the victim, requests SIM replacement
SIM Activation: New SIM card activated on attacker's phone
OTP Interception: All SMS messages now route to attacker
Account Takeover: Attacker uses intercepted codes to reset passwords

High-profile cryptocurrency thefts have used this technique to steal millions. The attack requires no technical sophistication—only social engineering skills.

Real-Time Phishing Proxies:

Even without SIM swapping, SMS and TOTP codes are vulnerable to real-time phishing:

Attacker creates convincing phishing page mimicking legitimate service
Victim enters username/password on fake page
Attacker proxies credentials to real site in real-time
Real site prompts for OTP; attacker's page prompts victim
Victim enters OTP; attacker immediately uses it on real site
Attacker gains authenticated session before OTP expires

Only hardware security keys with origin binding prevent this attack—they refuse to authenticate to fraudulent domains regardless of user action.

NIST Guidance on SMS

NIST SP 800-63B restricts SMS OTP to Authenticator Assurance Level 1, recommending against its use for higher-security applications. For AAL2 and AAL3, cryptographic authenticators (hardware tokens, smart cards) or authenticated protected channels are required.

Time-Based One-Time Passwords (TOTP)

TOTP is the most widely deployed form of app-based MFA. Understanding its cryptographic foundations reveals both its strengths and limitations.

The TOTP Algorithm (RFC 6238):

TOTP generates time-limited codes from a shared secret and the current time:

Shared Secret Setup: During enrollment, server generates a random secret (typically 160 bits) and shares it with the authenticator app (usually via QR code)
Time Counter: Both parties compute T = floor(current_unix_time / time_step), where time_step is typically 30 seconds
HMAC Computation: HMAC-SHA1(secret, T) produces a 160-bit hash
Truncation: Extract 4 bytes from the hash using dynamic offset
Modulo: Reduce to 6-digit code: code = truncated_value mod 10^6

The critical insight is that both the server and the authenticator app can independently compute the same code for any given time period—without communication. The server simply verifies that the user's submitted code matches its own computation.

totp_implementation.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
"""
Complete TOTP (Time-Based One-Time Password) Implementation
RFC 6238 Compliant
 
This implementation demonstrates the cryptographic foundations
of the authenticator apps you use daily.
"""
import hmac
import struct
import time
import base64
import secrets
from typing import Tuple
 
class TOTPAuthenticator:
    """
    TOTP implementation following RFC 6238.
    
    Security properties:
    - Secret must remain confidential on both server and client
    - Time synchronization required (typically ±1 step tolerance)
    - Each code valid for single time step (30 seconds default)
    """
    
    def __init__(
        self,
        secret: bytes,
        digits: int = 6,
        time_step: int = 30,
        hash_algorithm: str = 'sha1'
    ):
        """
        Initialize TOTP generator.
        
        Args:
            secret: Shared secret (minimum 128 bits, recommended 160 bits)
            digits: Number of digits in output code (typically 6 or 8)
            time_step: Time period in seconds for each code
            hash_algorithm: HMAC algorithm (sha1, sha256, sha512)
        """
        self.secret = secret
        self.digits = digits
        self.time_step = time_step
        self.hash_algorithm = hash_algorithm
        
        # Validate secret length (RFC recommends 160 bits for SHA-1)
        min_bits = {'sha1': 160, 'sha256': 256, 'sha512': 512}
        min_bytes = min_bits.get(hash_algorithm, 160) // 8
        if len(secret) < min_bytes // 2:  # Allow half of recommended minimum
            raise ValueError(
                f"Secret too short for {hash_algorithm}. "
                f"Minimum {min_bytes} bytes recommended."
            )
    
    def _hotp(self, counter: int) -> str:
        """
        HOTP algorithm (RFC 4226) - basis for TOTP.
        
        TOTP is essentially HOTP with time as the counter.
        """
        # Step 1: Convert counter to 8-byte big-endian integer
        counter_bytes = struct.pack('>Q', counter)
        
        # Step 2: Compute HMAC
        mac = hmac.new(
            self.secret,
            counter_bytes,
            self.hash_algorithm
        ).digest()
        
        # Step 3: Dynamic truncation
        # Use last nibble of hash as offset
        offset = mac[-1] & 0x0F
        
        # Extract 4 bytes starting at offset
        # Mask first bit to avoid signed/unsigned issues
        truncated = struct.unpack(
            '>I',
            bytes([mac[offset] & 0x7F]) + mac[offset+1:offset+4]
        )[0]
        
        # Step 4: Compute code as modulo 10^digits
        code = truncated % (10 ** self.digits)
        
        # Step 5: Zero-pad to required digits
        return str(code).zfill(self.digits)
    
    def generate(self, timestamp: float = None) -> str:
        """
        Generate TOTP code for current or specified time.
        
        Args:
            timestamp: Unix timestamp (defaults to current time)
            
        Returns:
            6-digit (or configured) TOTP code
        """
        if timestamp is None:
            timestamp = time.time()
        
        # Time counter: number of time_step intervals since epoch
        counter = int(timestamp) // self.time_step
        
        return self._hotp(counter)
    
    def verify(
        self,
        code: str,
        timestamp: float = None,
        tolerance: int = 1
    ) -> Tuple[bool, int]:
        """
        Verify a TOTP code with time tolerance.
        
        Args:
            code: The code to verify
            timestamp: Unix timestamp (defaults to current time)
            tolerance: Number of time steps to check before/after
            
        Returns:
            (is_valid, time_drift): Tuple of validity and clock drift
        """
        if timestamp is None:
            timestamp = time.time()
        
        current_counter = int(timestamp) // self.time_step
        
        # Check current step and surrounding steps within tolerance
        for offset in range(-tolerance, tolerance + 1):
            expected = self._hotp(current_counter + offset)
            
            # Constant-time comparison to prevent timing attacks
            if hmac.compare_digest(code, expected):
                return True, offset
        
        return False, 0
    
    @classmethod
    def generate_secret(cls, bits: int = 160) -> bytes:
        """Generate cryptographically secure random secret."""
        return secrets.token_bytes(bits // 8)
    
    @classmethod
    def secret_to_base32(cls, secret: bytes) -> str:
        """Convert secret to base32 for QR codes and manual entry."""
        return base64.b32encode(secret).decode('ascii')
    
    @classmethod
    def base32_to_secret(cls, base32_secret: str) -> bytes:
        """Convert base32 string back to bytes."""
        # Handle common user input issues
        cleaned = base32_secret.upper().replace(' ', '')
        return base64.b32decode(cleaned)
    
    def get_provisioning_uri(
        self,
        account_name: str,
        issuer: str = None
    ) -> str:
        """
        Generate otpauth:// URI for QR code enrollment.
        
        This URI format is scanned by authenticator apps to import
        the shared secret.
        """
        secret_b32 = self.secret_to_base32(self.secret)
        
        uri = (
            f"otpauth://totp/{account_name}"
            f"?secret={secret_b32}"
            f"&digits={self.digits}"
            f"&period={self.time_step}"
            f"&algorithm={self.hash_algorithm.upper()}"
        )
        
        if issuer:
            uri += f"&issuer={issuer}"
        
        return uri
 
 
def demonstrate_totp():
    """Demonstrate TOTP generation and verification."""
    
    # Generate a new secret
    secret = TOTPAuthenticator.generate_secret()
    print(f"Secret (hex): {secret.hex()}")
    print(f"Secret (base32): {TOTPAuthenticator.secret_to_base32(secret)}")
    
    # Create authenticator
    totp = TOTPAuthenticator(secret)
    
    # Generate current code
    current_code = totp.generate()
    print(f"
Current TOTP code: {current_code}")
    
    # Verify the code
    is_valid, drift = totp.verify(current_code)
    print(f"Verification: {'PASS' if is_valid else 'FAIL'}, drift={drift}")
    
    # Show codes over time
    print("
TOTP codes over 2-minute window:")
    base_time = time.time()
    for seconds in [0, 30, 60, 90, 120]:
        code = totp.generate(base_time + seconds)
        print(f"  T+{seconds:3d}s: {code}")
    
    # Generate provisioning URI
    uri = totp.get_provisioning_uri("user@example.com", "MyService")
    print(f"
Provisioning URI:
{uri}")
 
 
if __name__ == "__main__":
    demonstrate_totp()

Security Properties of TOTP:

Property	Protection Level	Notes
Replay resistance	Strong	Each code valid only for ~30 seconds
Offline brute force	Very strong	1,000,000 possibilities per 30s window
Secret compromise	Catastrophic	Attacker can generate all future codes
Phishing resistance	None	User can be tricked into entering valid codes
Man-in-the-middle	None	Real-time proxy attacks succeed

Time Synchronization Challenges:

TOTP requires that the server and client clocks agree (within tolerance). Drift handling involves:

Initial tolerance: Servers typically accept codes from T-1 and T+1 windows (90 seconds of validity)
Drift tracking: When a code from an offset window verifies, servers may record the user's apparent time drift
NTP dependencies: Mobile devices typically stay synchronized; servers must maintain accurate time
Replay prevention: Even within a valid window, servers should reject recently-used codes

TOTP vs. HOTP:

HOTP (HMAC-based OTP, RFC 4226) uses an event counter instead of time:

HOTP: Increments counter after each authentication
Pros: No time synchronization needed
Cons: Synchronization drift if user generates unused codes; codes don't expire

TOTP's automatic expiration makes it preferred for most applications.

The 30-Second Window

The 30-second window balances security against usability. Shorter windows increase security but frustrate users typing codes. Longer windows increase vulnerability to real-time interception. Most implementations accept codes from adjacent windows, creating an effective 90-second tolerance.

FIDO2/WebAuthn Hardware Keys

FIDO2 (Fast Identity Online 2) and its web component WebAuthn represent the gold standard for possession-based authentication. Unlike shared-secret systems (TOTP), FIDO2 uses public-key cryptography with keys that never leave the hardware device.

The FIDO2 Architecture:

WebAuthn API: JavaScript API in browsers for authentication ceremonies
CTAP (Client to Authenticator Protocol): Communication between browser and hardware authenticator
Authenticator: Hardware device (USB key, platform authenticator in smartphone/laptop)

Registration (Enrollment) Flow:

┌────────┐    ┌─────────┐    ┌────────────┐    ┌───────────┐
│  User  │    │ Browser │    │Authenticator│    │  Server   │
└───┬────┘    └────┬────┘    └──────┬─────┘    └─────┬─────┘
    │              │                │                │
    │   Request    │                │                │
    │   register   │                │                │
    │──────────────>                │                │
    │              │  Challenge +   │                │
    │              │  relying party │                │
    │              │<───────────────────────────────>│
    │    Touch     │                │                │
    │    prompt    │                │                │
    │<─────────────│  Create        │                │
    │ User touches │  credential    │                │
    │──────────────>                │                │
    │              │  Public key +  │                │
    │              │  attestation   │                │
    │              │<───────────────│                │
    │              │                │  Store public  │
    │              │                │  key           │
    │              │───────────────────────────────>│
    │              │                │                │

Key Security Properties:

Private key never leaves device: Key generation happens on-device; only public key sent to server
Origin binding: Each credential is bound to a specific origin (domain). Credentials for bank.com cannot be used on bank-phishing.com
User presence required: Physical touch/button press proves user is present at the device
User verification optional: Can require PIN or biometric on the authenticator itself

webauthn_registration.js
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
/**
 * WebAuthn Registration Flow
 * 
 * This demonstrates how a relying party (website) registers
 * a new FIDO2 credential with a user's hardware key.
 */
 
async function registerCredential(username) {
    // Step 1: Request challenge from server
    const challengeResponse = await fetch('/webauthn/register/begin', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ username })
    });
    
    const options = await challengeResponse.json();
    
    /**
     * Server returns PublicKeyCredentialCreationOptions:
     * {
     *   challenge: Uint8Array,  // Random challenge for replay protection
     *   rp: {                    // Relying Party (the website)
     *     name: "Example Corp",
     *     id: "example.com"      // Origin binding happens here
     *   },
     *   user: {                  // User being registered
     *     id: Uint8Array,        // Opaque user handle
     *     name: "user@example.com",
     *     displayName: "John Doe"
     *   },
     *   pubKeyCredParams: [      // Acceptable algorithms
     *     { type: "public-key", alg: -7 },   // ES256 (ECDSA P-256)
     *     { type: "public-key", alg: -257 }  // RS256 (RSA PKCS#1)
     *   ],
     *   authenticatorSelection: {
     *     authenticatorAttachment: "cross-platform", // USB key
     *     userVerification: "preferred",  // PIN/biometric if available
     *     residentKey: "required"         // Discoverable credential
     *   },
     *   timeout: 60000,
     *   attestation: "direct"  // Request attestation certificate
     * }
     */
    
    // Step 2: Call WebAuthn API - triggers authenticator interaction
    // Browser shows prompt, user touches hardware key
    let credential;
    try {
        credential = await navigator.credentials.create({
            publicKey: {
                challenge: Uint8Array.from(options.challenge, c => c.charCodeAt(0)),
                rp: options.rp,
                user: {
                    id: Uint8Array.from(options.user.id, c => c.charCodeAt(0)),
                    name: options.user.name,
                    displayName: options.user.displayName
                },
                pubKeyCredParams: options.pubKeyCredParams,
                authenticatorSelection: options.authenticatorSelection,
                timeout: options.timeout,
                attestation: options.attestation
            }
        });
    } catch (error) {
        if (error.name === 'NotAllowedError') {
            throw new Error('User cancelled or timeout');
        }
        throw error;
    }
    
    /**
     * Authenticator returns PublicKeyCredential:
     * {
     *   id: string,             // Credential ID (base64)
     *   rawId: ArrayBuffer,     // Raw credential ID
     *   response: {
     *     clientDataJSON: ArrayBuffer,    // Challenge, origin, type
     *     attestationObject: ArrayBuffer  // Public key + attestation
     *   },
     *   type: "public-key"
     * }
     */
    
    // Step 3: Send credential to server for storage
    const registrationResult = await fetch('/webauthn/register/complete', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            id: credential.id,
            rawId: arrayBufferToBase64(credential.rawId),
            response: {
                clientDataJSON: arrayBufferToBase64(
                    credential.response.clientDataJSON
                ),
                attestationObject: arrayBufferToBase64(
                    credential.response.attestationObject
                )
            },
            type: credential.type
        })
    });
    
    return await registrationResult.json();
}
 
/**
 * WebAuthn Authentication Flow
 */
async function authenticate(username) {
    // Step 1: Request challenge
    const challengeResponse = await fetch('/webauthn/authenticate/begin', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ username })
    });
    
    const options = await challengeResponse.json();
    
    /**
     * Server returns PublicKeyCredentialRequestOptions:
     * {
     *   challenge: Uint8Array,
     *   rpId: "example.com",
     *   allowCredentials: [    // Credentials user can use
     *     { type: "public-key", id: Uint8Array }
     *   ],
     *   userVerification: "preferred",
     *   timeout: 60000
     * }
     */
    
    // Step 2: Get assertion from authenticator
    const assertion = await navigator.credentials.get({
        publicKey: {
            challenge: Uint8Array.from(options.challenge, c => c.charCodeAt(0)),
            rpId: options.rpId,
            allowCredentials: options.allowCredentials.map(cred => ({
                type: cred.type,
                id: Uint8Array.from(atob(cred.id), c => c.charCodeAt(0))
            })),
            userVerification: options.userVerification,
            timeout: options.timeout
        }
    });
    
    /**
     * Authenticator signs the challenge with the private key.
     * Server verifies signature using stored public key.
     * 
     * Critical: The signed data includes the origin (rpId).
     * A phishing site would have a different origin,
     * so signatures from legitimate credentials won't verify.
     */
    
    // Step 3: Send assertion to server
    const verifyResult = await fetch('/webauthn/authenticate/complete', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            id: assertion.id,
            rawId: arrayBufferToBase64(assertion.rawId),
            response: {
                clientDataJSON: arrayBufferToBase64(
                    assertion.response.clientDataJSON
                ),
                authenticatorData: arrayBufferToBase64(
                    assertion.response.authenticatorData
                ),
                signature: arrayBufferToBase64(
                    assertion.response.signature
                )
            },
            type: assertion.type
        })
    });
    
    return await verifyResult.json();
}
 
function arrayBufferToBase64(buffer) {
    return btoa(String.fromCharCode(...new Uint8Array(buffer)));
}

Why FIDO2 Defeats Phishing:

The origin binding in FIDO2 provides cryptographic phishing protection:

User registers YubiKey for bank.com
Credential is bound to bank.com origin
User visits phishing site bank-secure.fake
Phishing site requests authentication
YubiKey refuses: No credential exists for bank-secure.fake
Even if user is completely fooled, credential won't work on wrong origin

This is fundamentally different from TOTP, where a fooled user can type valid codes into any site.

Authenticator Types:

Type	Examples	Security Level	User Experience
Roaming (Cross-platform)	YubiKey, Titan	Highest	Carry device separately
Platform	Windows Hello, Touch ID, Face ID	High	Built into device
Virtual	Software emulation	Lower	No hardware required

Attestation:

FIDO2 authenticators can provide cryptographic attestation—proof that a credential was created by a genuine hardware device from a known manufacturer. Enterprises can use attestation to enforce that only approved authenticator models are registered.

Passkeys: FIDO2 Goes Mainstream

Passkeys are FIDO2 credentials synchronized across devices via cloud keychains (Apple, Google, Microsoft). They provide the phishing resistance of hardware keys with the convenience of passwords—users never see or type a secret. Major platforms and websites are rapidly adopting passkeys as a path toward passwordless authentication.

Push-Based Authentication

Push notification authentication has gained popularity for its user experience: instead of typing a code, users simply tap "Approve" on their smartphone. However, this convenience introduces distinct security considerations.

How Push Authentication Works:

User attempts to log in (enters username/password)
Server sends authentication request to user's registered phone
Phone displays push notification with context (service, location, time)
User reviews and taps Approve or Deny
Response sent back to server via secure channel
Server grants or denies access

Advantages:

Superior UX: One tap vs. typing 6-digit code
Context display: Shows authentication details (where, what)
Bidirectional channel: Can transmit additional data (deny reason)
No secret handling: User never enters or sees codes

The MFA Fatigue Attack:

Push authentication's convenience becomes a vulnerability when exploited:

Attacker has valid username/password (from breach)
Attacker attempts login repeatedly (dozens to hundreds of times)
User's phone bombarded with authentication requests
User, frustrated or confused, accidentally taps Approve
Attacker gains access

This attack, known as MFA fatigue or push bombing, succeeded against major organizations including Uber (2022) and Cisco (2022).

Vulnerable Push Implementation

•Simple Approve/Deny buttons
•No rate limiting on requests
•Minimal context displayed
•No challenge verification
•Automatic approval options

Hardened Push Implementation

•Number matching challenge
•Aggressive rate limiting (3/hour)
•Detailed context (IP, location, device)
•Explicit 'This wasn't me' button
•Anomaly detection integration

Number Matching: The MFA Fatigue Countermeasure:

Number matching transforms push authentication from passive approval to active verification:

Login page displays a random 2-digit number (e.g., "42")
Push notification asks user to enter the number they see
User must switch to login page, note the number, return to phone, enter it
Only matching entry approves authentication

This defeats MFA fatigue because:

Attacker cannot predict the number to tell victim
User must actively engage with legitimate login session
Accidental approvals become impossible

Device Trust and Contextual Signals:

Sophisticated push implementations incorporate risk signals:

Geographic impossibility: Login from Moscow 10 minutes after login from New York
Behavioral anomaly: Login at 3 AM when user typically logs in 9-5
Device fingerprint: New device configuration
Network reputation: Known malicious IP address

High-risk contexts can trigger additional verification (step-up authentication) or automatic denial.

Push Authentication Requires Secure Channel

Push authentication's security depends on the integrity of the notification channel. Attackers who compromise the push notification infrastructure (device, network, or cloud provider) can intercept and manipulate authentication requests. Enterprise implementations should use encrypted push channels with certificate pinning.

MFA in Operating Systems

Operating systems implement MFA through various mechanisms, each with distinct architectural approaches and security properties.

Windows Hello for Business:

Windows Hello provides passwordless and multi-factor authentication through platform authenticators:

Biometric factors: Facial recognition (infrared camera), fingerprint scanner
PIN: Device-bound PIN (distinct from domain password)
Hardware protection: TPM stores private keys; Secure Enclave on supported hardware
Enterprise features: Certificate-based authentication, integration with Azure AD and ADFS

The architecture separates the authentication credential from network-transmitted tokens:

┌─────────────────┐    ┌──────────────────┐    ┌──────────────┐
│   Biometric/    │    │    Windows       │    │   Identity   │
│     PIN         │───>│    Hello         │───>│   Provider   │
│   (local)       │    │   (local auth)   │    │   (AD/AAD)   │
└─────────────────┘    └──────────────────┘    └──────────────┘
        │                       │                      │
   Never leaves           Issues signed           Verifies
   device                 assertion               assertion

Linux PAM-Based MFA:

Linux implements MFA through PAM module stacking:

# /etc/pam.d/ssh-mfa
auth    required    pam_unix.so          # First factor: password
auth    required    pam_google_authenticator.so  # Second factor: TOTP
auth    required    pam_u2f.so           # Alternative: hardware key

Each required module must succeed for authentication to proceed. PAM's flexibility allows complex policies:

Require all factors (required)
Accept any one factor (sufficient)
Different requirements for local vs. remote login
Conditional requirements based on user groups

pam_totp_module.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
/**
 * Simplified PAM TOTP Module
 * 
 * Demonstrates how a second factor integrates with PAM.
 * Production implementations should use established modules
 * (pam_google_authenticator, pam_oath).
 */
 
#include <security/pam_modules.h>
#include <security/pam_ext.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <openssl/hmac.h>
 
#define MAX_CODE_LEN 10
#define TIME_STEP 30
#define DIGITS 6
 
/**
 * Read user's TOTP secret from secure storage.
 * In practice: ~/.google_authenticator or directory service
 */
static int get_user_secret(
    const char *user,
    unsigned char *secret,
    size_t *secret_len
) {
    char path[256];
    snprintf(path, sizeof(path), "/var/lib/totp/%s.secret", user);
    
    FILE *f = fopen(path, "r");
    if (!f) return -1;
    
    // Read base32-encoded secret and decode
    // ... (decode implementation omitted for brevity)
    
    fclose(f);
    return 0;
}
 
/**
 * Generate expected TOTP code for current time.
 */
static int generate_totp(
    const unsigned char *secret,
    size_t secret_len,
    char *code_out
) {
    time_t now = time(NULL);
    uint64_t counter = now / TIME_STEP;
    
    // Convert counter to big-endian bytes
    unsigned char counter_bytes[8];
    for (int i = 7; i >= 0; i--) {
        counter_bytes[i] = counter & 0xFF;
        counter >>= 8;
    }
    
    // HMAC-SHA1
    unsigned char hmac_result[20];
    unsigned int hmac_len;
    HMAC(EVP_sha1(),
         secret, secret_len,
         counter_bytes, 8,
         hmac_result, &hmac_len);
    
    // Dynamic truncation
    int offset = hmac_result[19] & 0x0F;
    uint32_t truncated = 
        ((hmac_result[offset] & 0x7F) << 24) |
        ((hmac_result[offset+1] & 0xFF) << 16) |
        ((hmac_result[offset+2] & 0xFF) << 8) |
        (hmac_result[offset+3] & 0xFF);
    
    // Generate code
    uint32_t code = truncated % 1000000;
    snprintf(code_out, MAX_CODE_LEN, "%06u", code);
    
    return 0;
}
 
/**
 * Constant-time string comparison
 */
static int secure_compare(const char *a, const char *b, size_t len) {
    unsigned char result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];
    }
    return result == 0;
}
 
/**
 * PAM authentication function.
 * Called by PAM framework during authentication.
 */
PAM_EXTERN int pam_sm_authenticate(
    pam_handle_t *pamh,
    int flags,
    int argc,
    const char **argv
) {
    const char *user;
    char *response = NULL;
    int retval;
    
    // Get username from PAM
    retval = pam_get_user(pamh, &user, NULL);
    if (retval != PAM_SUCCESS) {
        return retval;
    }
    
    // Load user's TOTP secret
    unsigned char secret[64];
    size_t secret_len;
    if (get_user_secret(user, secret, &secret_len) != 0) {
        pam_syslog(pamh, LOG_ERR, "No TOTP secret for user %s", user);
        return PAM_AUTHINFO_UNAVAIL;
    }
    
    // Prompt for TOTP code
    retval = pam_prompt(pamh, PAM_PROMPT_ECHO_OFF,
                        &response, "Verification code: ");
    if (retval != PAM_SUCCESS || !response) {
        return PAM_AUTH_ERR;
    }
    
    // Generate expected codes for current window (±1 step)
    for (int offset = -1; offset <= 1; offset++) {
        char expected[MAX_CODE_LEN];
        // Generate for (now + offset * TIME_STEP)
        generate_totp(secret, secret_len, expected);
        
        if (secure_compare(response, expected, DIGITS)) {
            // Clear sensitive data
            memset(response, 0, strlen(response));
            free(response);
            memset(secret, 0, sizeof(secret));
            
            pam_syslog(pamh, LOG_INFO, 
                       "TOTP authentication successful for %s", user);
            return PAM_SUCCESS;
        }
    }
    
    // Clear sensitive data on failure too
    memset(response, 0, strlen(response));
    free(response);
    memset(secret, 0, sizeof(secret));
    
    pam_syslog(pamh, LOG_WARNING,
               "TOTP authentication failed for %s", user);
    return PAM_AUTH_ERR;
}
 
/**
 * Required PAM module entry points
 */
PAM_EXTERN int pam_sm_setcred(
    pam_handle_t *pamh, int flags, int argc, const char **argv
) {
    return PAM_SUCCESS;
}

macOS Authentication:

macOS implements MFA through several mechanisms:

Touch ID: Fingerprint authentication on MacBooks with Touch ID sensor
Apple Watch: Proximity-based unlock and authentication
Smart Card Support: PIV-compatible smart cards for enterprise environments
Secure Enclave: Hardware-protected storage for biometric data and keys

Enterprise MFA Integration:

Large organizations often integrate OS-level authentication with enterprise identity providers:

Operating System	Enterprise Integration	MFA Methods
Windows	Azure AD, ADFS, Okta	Windows Hello, FIDO2, Push, TOTP
macOS	Jamf, Azure AD	Touch ID, Smart Cards, Enterprise SSO
Linux	LDAP, FreeIPA, SSSD	PAM modules, Smart Cards, FIDO2

Recovery and Backup Codes:

MFA creates a availability challenge: if users lose their second factor, they're locked out. OS implementations must address recovery:

Backup codes: Pre-generated codes stored securely offline
Recovery keys: Master keys stored in secure location (safe, escrow)
Alternative factors: Register multiple authenticators
Administrator recovery: Privileged override for enterprise scenarios

Defense in Depth

OS-level MFA should be complemented by application-level MFA for sensitive operations. A user authenticated to the OS should still require MFA to access financial systems, privileged administrative consoles, or sensitive data repositories. This limits the blast radius of compromised sessions.

MFA Deployment Considerations

Deploying MFA at scale involves balancing security, usability, cost, and operational complexity. Organizations must make strategic decisions about which factors to support and how to handle edge cases.

Factor Selection Matrix:

Factor Type	Security	UX	Cost	Deployment Complexity
SMS OTP	Low	Medium	Low	Low
TOTP App	Medium	Medium	Very Low	Low
Push App	Medium-High	High	Medium	Medium
Hardware Key (FIDO2)	Highest	Medium	High	Medium
Platform Biometrics	High	Highest	Varies	Low

User Enrollment Strategies:

Mandatory immediate: All users must enroll at next login
- Pro: Complete coverage quickly
- Con: Support burden, user resistance
Gradual rollout: Start with high-risk groups, expand
- Pro: Manageable support load, learn from early adopters
- Con: Delayed security benefit for later groups
Risk-based: Require MFA only for high-risk operations/locations
- Pro: Minimal friction for routine access
- Con: Complexity in defining and maintaining risk policies
Opt-in with incentives: Users choose to adopt
- Pro: Better user reception
- Con: Incomplete coverage, self-selection bias

Common MFA Deployment Pitfalls

•Account recovery bypass: Weak recovery mechanisms that attackers exploit (security questions, support social engineering)
•Incomplete coverage: MFA on web portal but not VPN, or main application but not admin console
•Single authenticator: If user only has one enrolled device and loses it, they're locked out
•Legacy protocol exceptions: Old applications using protocols that don't support MFA (e.g., IMAP for email)
•Session handling gaps: MFA at login but no re-authentication for sensitive operations
•Insufficient monitoring: Not alerting on MFA failures, setting additions, or bypass attempts

Adaptive/Risk-Based Authentication:

Modern authentication systems adjust requirements based on contextual risk:

if (login_from_trusted_device && 
    login_from_familiar_location &&
    normal_time_of_day &&
    no_recent_failures) {
    // Low risk: password only
} else if (login_from_new_device ||
           login_from_new_location) {
    // Medium risk: require MFA
} else if (login_from_tor_exit_node ||
           login_from_high_risk_country ||
           impossible_travel_detected) {
    // High risk: require hardware MFA + additional verification
}

This approach optimizes user experience for routine access while strengthening authentication for anomalous scenarios.

Monitoring and Incident Response:

MFA systems generate valuable security intelligence:

Failed MFA attempts: May indicate credential compromise
MFA factor changes: Adding new factors could be account takeover preparation
MFA bypass attempts: Attackers probing for weaknesses
Unusual factor usage: Backup code use warrants investigation
MFA fatigue patterns: Repeated prompts without approval

Regulatory Requirements

Many compliance frameworks now mandate MFA: PCI-DSS requires MFA for administrative access, HIPAA recommends it for electronic protected health information, and NIST 800-171 requires it for controlled unclassified information. Understanding regulatory requirements helps justify MFA investment to stakeholders.

Summary and Key Takeaways

Multi-factor authentication transforms the security equation by requiring independent proofs of identity from different factor categories. This page has explored the theoretical foundations, implementation mechanisms, and practical considerations for MFA deployment.

Key Takeaways

•MFA requires factors from different categories — Password plus security question is not true MFA. Factors must be knowledge, possession, AND/OR inherence.
•Factor compromise probabilities multiply — If password has 1% chance and token has 0.01% chance of compromise, combined probability is 0.0001%.
•TOTP is widely deployed but phishable — Time-based codes are vulnerable to real-time interception by sophisticated phishing proxies.
•FIDO2/WebAuthn provides phishing-resistant authentication — Origin binding cryptographically prevents credentials from working on fraudulent sites.
•Push authentication is convenient but vulnerable to fatigue attacks — Number matching and rate limiting are essential countermeasures.
•OS platforms implement MFA through distinct architectures — PAM on Linux, Windows Hello on Windows, and Secure Enclave on Apple platforms.
•MFA deployment requires holistic planning — Consider recovery, coverage gaps, legacy systems, and monitoring alongside factor selection.

Looking Ahead:

While MFA significantly strengthens authentication, certain scenarios demand even stronger identity assurance—or face unique constraints that MFA cannot address through possession alone. The next page explores Biometrics—authentication through inherent physical characteristics that cannot be forgotten or transferred.

Page Complete

You now understand the theoretical foundations and practical implementations of multi-factor authentication. This knowledge enables you to evaluate, design, and deploy MFA solutions that dramatically improve authentication security while maintaining usability.