Multi-Factor Authentication Vulnerabilities

MFA meaningfully raises the security bar compared with password-only authentication, but “meaningfully raises the bar” does not mean “unbreakable.”

Attackers can sometimes bypass MFA without compromising the intended second factor itself. The weakness may exist in how the factor is generated, delivered, verified, enrolled, or recovered, or in an alternative authentication path that does not enforce MFA consistently.

The sections that follow examine the major ways this happens in practice:

Generation weaknesses — flaws in how one-time codes or other authentication challenges are created.
Verification weaknesses — flaws in how the server validates the supplied factor.
Delivery weaknesses — attacks against the channel used to deliver the second factor.
MFA-flow bypasses — paths that allow an attacker to reach an authenticated state without completing the required MFA step.
Recovery and enrollment weaknesses — account-recovery or MFA-enrollment mechanisms that provide an easier path around the existing factor.
Social engineering — attacks that persuade the legitimate user or support process to disclose, approve, or replace the second factor.
Session theft — attacks that don't defeat MFA directly but steal an already-authenticated session after MFA has successfully completed.

MFA can protect the authentication step without necessarily protecting every alternative path to an authenticated session.

This vulnerability class focuses specifically on how the one-time code is generated. It is separate from weaknesses in how the code is delivered, verified, or otherwise handled, which the following sections cover.

OTP length directly affects the size of the possible code space. A 4-digit numeric OTP has only 10,000 possible values, while a 6-digit OTP has 1,000,000. However, the practical difficulty of guessing an OTP also depends heavily on controls such as attempt limits, expiration, and whether failed attempts are detected and throttled.

Weak or predictable generation is more serious. Standardized OTP systems such as HOTP and TOTP use HMAC-based algorithms with a securely generated per-user secret. A homegrown implementation that derives codes from predictable values, such as a timestamp, counter, or non-cryptographic pseudo-random generator, can make the resulting codes predictable.

For example:

// Weak — predictable seed and non-cryptographic PRNG
mt_srand(time());
$otp = mt_rand(100000, 999999);

// Cryptographically secure random value
$otp = random_int(100000, 999999);

random_int() is appropriate when an application genuinely needs to generate a random numeric token. It does not, however, turn a custom OTP system into TOTP or HOTP. Where a standardized OTP protocol is required, the application should implement the appropriate algorithm and lifecycle rather than inventing its own.

Expiration is another part of the generation lifecycle. An OTP that remains valid for an unnecessarily long period gives an attacker more time to obtain and use it. The effective attack window is determined not only by the number of possible codes, but also by how long a code remains valid and how many verification attempts the application permits.

Unpredictable generation + appropriate code length + limited lifetime + restricted verification attempts

A correctly implemented single-use OTP should become invalid immediately after it has been successfully used. The vulnerability occurs when the server checks only whether a code is currently valid, without separately tracking whether that specific code has already been accepted.

For example, suppose a server issues:

OTP: 481729
Valid until: 10:05

The legitimate user submits 481729, and authentication succeeds. If the server doesn't record that the code has already been consumed, the same code may still be accepted again before 10:05.

An attacker who has observed the code — through shoulder surfing, exposed logs, compromised notifications, or another interception mechanism — may therefore be able to replay it and authenticate again while it remains valid.

The intended flow is:

Code generated → Code verified → Authentication succeeds → Code marked as used → Same code rejected

The key distinction is:

Validity: “Is this code currently acceptable?”
Replay protection: “Has this code already been successfully accepted?”

An OTP that remains valid after successful use can turn a one-time credential into a reusable authentication token.

This vulnerability is distinct from the login rate-limiting failure covered in Lesson 3.4. It occurs when the OTP verification endpoint itself lacks effective rate limiting, even though the initial username/password login endpoint may be well protected.

A 6-digit numeric OTP has exactly 1,000,000 possible values:
000000 → 999999

If the application allows unlimited or excessive attempts against the OTP verification endpoint, an attacker can repeatedly submit candidate codes until one is accepted.

This can remain exploitable even when the main login endpoint has strong protections. For example:

Password endpoint → Strong rate limiting ✓ → OTP verification endpoint → No meaningful rate limiting ✗ → Repeated OTP guesses

The important security boundary is therefore the specific endpoint that verifies the OTP, not merely the login flow as a whole.

The practical feasibility of guessing depends on several factors, including the number of allowed attempts, OTP expiration, lockout or challenge behavior, and whether failed attempts are tracked for the relevant authentication session. Without effective restrictions, however, the nominal size of the OTP space provides far less protection than it appears to.

If an attacker can submit unlimited OTP guesses, the strength of the OTP becomes largely irrelevant.

Instead of attacking the OTP directly, an attacker may obtain it through a side channel. In these cases, the OTP generation and verification mechanisms may be perfectly correct, the problem is that the secret is exposed somewhere it was never supposed to appear.

Common examples include:

API response leakage: An OTP is accidentally included in an API response even though the client application does not need it. This can happen when debugging code or test functionality is left enabled in production.

Server or application logs: Sensitive OTP values are written to logs during request processing, error handling, or debugging. Anyone with access to those logs may be able to recover active codes.

SMS interception: SMS-based OTPs can be compromised through attacks such as SIM swapping, where an attacker socially engineers a mobile carrier into transferring the victim's phone number to a SIM under the attacker's control.

URL exposure: An OTP placed in a URL query parameter can be recorded in browser history, proxy or server logs, analytics systems, or other infrastructure. Depending on the browser's referrer policy and the destination, URL information can also potentially be disclosed through the Referer header to another resource.

For example, this is dangerous:

/verify?otp=481729

The OTP may have been transmitted over HTTPS, but that does not prevent other systems from recording the URL after the request reaches the application.

Protecting an OTP means protecting the entire path it travels through, not just the algorithm that generates it.

MFA fatigue, also called push bombing, is a social-engineering attack aimed specifically at push-notification-based MFA.

The attacker first obtains the victim's password through another means. They then repeatedly initiate login attempts, generating a stream of MFA approval notifications on the victim's device:

Attacker attempts login → MFA approval request → Attacker attempts again → Another MFA approval request → Repeated until the victim approves

The attacker is not breaking the cryptography of the MFA system. Instead, they exploit notification fatigue, confusion, or the victim's assumption that the prompts are legitimate. The attacker may also impersonate IT support or another trusted party and pressure the victim into approving a request.

The technique received significant attention after the 2022 Uber breach, which was publicly reported as involving repeated MFA prompts combined with social engineering of the targeted employee.

Technical MFA bypass: defeat or circumvent the mechanism itself.
MFA fatigue: persuade the legitimate user to complete the MFA step for the attacker.

MFA recovery mechanisms are intended to help legitimate users regain access when they lose their authenticator, but they can also become an alternative path around MFA.

This is specifically about MFA's own fallback mechanisms — such as backup codes, “trust this device” functionality, or a “lost your authenticator” recovery path. Password-reset and account-recovery vulnerabilities are separate subjects and are covered elsewhere.

The critical requirement is that a recovery path must provide security equivalent to the factor it replaces. If the fallback mechanism is substantially weaker, an attacker will target that path instead of defeating the primary MFA mechanism.

Examples include:

Predictable backup codes: codes are generated with insufficient randomness and can be guessed.
Indefinite backup codes: codes remain valid permanently even after they have been exposed or used.
Unprotected regeneration: new backup codes can be generated without sufficiently re-authenticating the account owner.
Persistent trusted devices: a device remains trusted indefinitely, with no reasonable expiration or remote revocation mechanism.
Weak authenticator recovery: replacing a lost MFA device requires only a lower-assurance proof that an attacker may already possess.

The testing question is:

If I cannot complete the normal MFA challenge, is there another path that grants the same authenticated state with substantially weaker proof?

MFA is only as strong as the weakest link in its authentication chain. Code generation, verification, delivery, enrollment, and recovery are separate places where a security flaw can exist, and strength in one component does not compensate for weakness in another.

A properly implemented MFA system needs to protect the entire lifecycle — from factor generation and enrollment through delivery, verification, session establishment, and recovery.

MFA isn't a single security feature. It is a chain of security decisions, and the chain is only as strong as its weakest link.