Multi-Factor Authentication (MFA) Explained

Multi-factor authentication (MFA) is a security control that requires a user to present two or more independent pieces of evidence before an account grants access. Because passwords alone are routinely stolen, guessed, or reused, MFA dramatically raises the cost of account takeover by forcing an attacker to compromise more than one factor. Understanding how the factors work, and where each type fails, is essential for designing login systems that resist real-world attacks.

The Three Authentication Factors

Authentication factors are grouped into categories based on what they prove about the person logging in. Strong MFA combines factors from different categories, because two items in the same category share the same weaknesses.

• Something you know (knowledge): a password, passphrase, PIN, or answer to a security question.
• Something you have (possession): a phone running an authenticator app, a hardware security key, or a smart card.
• Something you are (inherence): a biometric such as a fingerprint, face, or voice pattern.

Location and behavior are sometimes described as additional signals, but they are typically used to adjust risk rather than to serve as a primary factor. True MFA requires factors from at least two distinct categories. Requiring a password plus a security question is not real MFA, because both are knowledge factors an attacker can phish or research at the same time.

How a Typical MFA Flow Works

Most MFA deployments layer a second check on top of the primary password step. A common sequence looks like this:

1. The user submits a username and password over TLS.
2. The server verifies the password hash and, if valid, marks the session as partially authenticated.
3. The server challenges the user for a second factor rather than issuing a full session.
4. The user provides the second factor, such as a one-time code or a security key signature.
5. The server validates the second factor and only then issues an authenticated session token.

A minimal two-phase exchange makes the pending state explicit:

POST /login       {user, password}       -> 200 {mfa_required: true, mfa_token}
POST /login/mfa   {mfa_token, otp}        -> 200 {session}    # full session only here

Keeping the session in a pending state between steps two and five is important. If the application issues a full session cookie after the password check alone, an attacker who steals that intermediate token can bypass the second factor entirely. Well-built systems bind the pending state to the eventual factor verification.

Common Second-Factor Methods

One-Time Passwords

Time-based and counter-based one-time passwords are widely used because they work offline in an authenticator app. The app and server share a secret and derive short numeric codes from it. These algorithms are covered in depth in TOTP and HOTP. One-time passwords resist password reuse and database leaks, but they can still be phished, because a user can be tricked into typing a valid code into a fake site.

Push Notifications

Push-based MFA sends an approval prompt to a registered device. The user taps approve or deny. This is convenient, but it introduces a risk called MFA fatigue, where an attacker who already has the password floods the victim with prompts until one is approved by mistake. Number matching, which forces the user to type a code shown on the login screen into the app, is a mitigation.

SMS and Email Codes

Codes sent by text message or email are better than nothing, but they are the weakest common factor. SMS is vulnerable to SIM-swapping, interception, and social engineering of mobile carriers. Email codes collapse to single-factor security if the email account itself is protected only by a password.

Hardware Security Keys

Security keys built on public-key cryptography are the strongest widely available option. They are examined in FIDO2 and WebAuthn. Because the key signs a challenge that is cryptographically bound to the real site's origin, it cannot be replayed against a phishing page, making it phishing-resistant by design.

Phishing-Resistant MFA

Not all MFA stops modern attacks. Real-time phishing proxies sit between the victim and the legitimate site, relaying the password and any typed one-time code instantly, then hijacking the resulting session. This defeats OTP and push approvals.

Phishing-resistant MFA closes this gap by binding the authentication to the origin and the channel:

• The authenticator verifies the exact web origin before responding, so a lookalike domain receives nothing usable.
• The cryptographic response is a signature over a server challenge, never a static secret the user can retype elsewhere.
• The private key never leaves the hardware, so it cannot be captured in transit or copied from a database.

FIDO2 security keys and platform authenticators are the primary examples. For high-value accounts, moving from OTP to phishing-resistant methods is one of the highest-impact upgrades available.

Deployment Pitfalls to Avoid

MFA implementations fail in predictable ways. Watch for these weaknesses during design and review:

• Weak recovery flows. If a help desk resets MFA after only a knowledge-based question, the recovery path becomes the easiest attack surface. Recovery must be as strong as enrollment.
• Bypassable endpoints. Legacy protocols, API tokens, and older mail clients sometimes skip MFA. Attackers hunt for these gaps.
• Missing rate limits. Without throttling and lockout, six-digit codes can be brute-forced. Limit attempts and expire codes quickly.
• Insecure enrollment. Enrolling a second factor while only a password is present lets an attacker who already has the password register their own device.

Combining MFA with strong password security and monitoring for credential-stuffing attacks produces defense in depth rather than a single brittle wall.

Key Takeaways

• MFA requires evidence from at least two of the three categories: knowledge, possession, and inherence.
• Keep the session in a pending state until the second factor is verified, so the password step alone never grants access.
• SMS and email codes are the weakest factors; push and OTP are stronger but still phishable by real-time proxies.
• Phishing-resistant MFA based on origin-bound public-key cryptography defeats relay and lookalike-domain attacks.
• Recovery, enrollment, and legacy endpoints are common bypasses that must be secured as carefully as the main login.