MFA Bypass Patterns

Multi-factor authentication requires a second verification step after a correct password. The cryptographic constructions behind TOTP (RFC 6238) and FIDO2 are not broken by practical attacks. What is bypassed in the field is the application logic around the second factor: the state machine, the rate limiting, the recovery flows, and the assumptions about which endpoints require MFA to have completed.

OTP Relay

A TOTP code is valid for a short window, typically 30 seconds with one code of tolerance on either side. An attacker who has stolen credentials but cannot generate a TOTP code can relay it in real time. The attacker presents a credential phishing page that looks identical to the legitimate login. When the victim submits their password, the attacker immediately submits it to the real service. The real service sends a TOTP prompt; the phishing page presents the same prompt to the victim. The victim enters their TOTP code on the phishing page; the attacker relays it to the real service within the 30-second window. The attacker receives a valid authenticated session.

TOTP relay does not require breaking any cryptography. It treats the TOTP code as a short-lived password and relays it before expiration. FIDO2/WebAuthn hardware tokens are resistant to this: the challenge-response is bound to the origin domain, so a response generated for a phishing domain is not accepted by the legitimate domain.

Push Fatigue

Push-based MFA sends a notification to the user's device asking them to approve a login. If the application does not include context in the notification (location, device, application) or sends multiple push requests in succession, users sometimes approve a request they did not initiate, either out of confusion or to stop repeated notifications.

Some implementations allow users to approve without viewing any context. Number matching, where the user must match a number shown on the login screen with a number in the push notification, eliminates blind approval. Applications that do not implement number matching or contextual information in push notifications are exposed to push fatigue.

State Machine Bypass

An application that implements MFA as two separate pages or endpoints must enforce that the second factor was completed before granting access. If authenticated session state is set after password verification but before MFA verification, and if any endpoint checks only for authenticated session state rather than fully-authenticated state, an attacker with valid credentials can access those endpoints without completing MFA.

This appears in applications where the session is marked as authenticated at the password step and an additional session flag marks MFA completion. Endpoints that check only the first flag are bypassable. All access control decisions must require the MFA-complete flag for users enrolled in MFA.

Recovery Path Weaknesses

Account recovery paths exist to restore access when a second factor is lost. These paths often require only email verification or answering security questions. An attacker who has compromised the victim's email account can use the account recovery path to bypass MFA entirely. The second factor's strength is bounded by the weakest account recovery option available.

Recovery codes, pre-generated at enrollment, are the standard fallback. They are single-use and should be treated as equivalent to the password in terms of storage and handling. Applications that allow recovery by email alone reduce MFA to single-factor authentication for anyone who controls the victim's email.