MFA and OTP Bypass

Multi-factor authentication is supposed to mean a stolen password is not enough. In practice the second step is frequently optional, tamperable, or guessable, so the extra factor collapses. This page covers both halves: the logic flaws that skip the second step entirely, and the code weaknesses that defeat a one-time password. Practice on a free live target.

What a second factor should guarantee

After the password, the server should demand a second proof, verify it server-side, and only then grant an authenticated session. Every bypass below is a place where one of those links is missing: the demand is skippable, the verification is tamperable, or the proof itself is weak.

Step 1: is the second step even enforced?

The most common MFA bypass is that the second step is not enforced on the server at all. The first factor succeeds, the UI shows a code prompt, but nothing stops you going straight to the authenticated area. Test it directly:

• Complete the password step, then browse directly to a post-login URL or call a post-login API. If it works, the second step was presentational only.
• Check whether your session is already authenticated after step one, before you submit any code.
• Remove the MFA parameter from the verify request entirely. Some flows default to pass when the field is absent.

If any of these lands, you never needed the code.

Step 2: tamper the verification exchange

If the second step is enforced, attack the request and response that carry it. Intercept the verify call and try:

{"verified": false}   ->   {"verified": true}
{"status": "fail"}    ->   {"status": "ok"}

A flow that trusts a client-supplied verified flag, or that reflects a status you can flip, hands you the bypass. Also try swapping the account the verification is for: complete MFA on an account you control while changing the session or user id to the victim's, so your valid code authenticates their session.

Step 3: attack the code itself

When a numeric one-time code is genuinely required, the code is often the weak point:

[ ] Brute 4-6 digit codes (0000-9999 / 000000-999999) with no/weak rate limit
[ ] Re-submit an OLD code: is it still accepted (no single-use)?
[ ] Wait past the stated window: does it still work (no expiry)?
[ ] Race: fire many verify requests in parallel against one code
[ ] Is the code ever returned in the response body, a header, or a redirect?

A six-digit code is only a million values, a four-digit one only ten thousand. Without strict rate limiting and single-use enforcement that space is searchable in minutes. Code reuse and missing expiry are just as fatal: if yesterday's code still verifies, the "one-time" guarantee is gone. And always check whether the code leaks back to you in the HTTP response, a header, or a redirect, which turns the whole step into a formality.

The recovery-flow downgrade

Even a solid MFA step often sits beside a weaker backup path. Backup codes, "lost my device," and SMS-fallback flows are frequently shorter, unthrottled, or less carefully verified than the primary factor. If the main OTP is locked down, pivot to the recovery flow and attack that instead, because defenders routinely harden the front door and leave the back one open.

Fixing it

• Enforce the second factor on the server at the final sensitive step, never as a UI-only gate, and bind it to the same session and account as the first factor.
• Never trust a client-supplied verification flag. Decide pass or fail server-side.
• Make one-time codes single-use, short-lived, and strictly rate-limited, and invalidate a code after a few wrong attempts.
• Hold recovery flows to the same standard as the primary factor, and prefer phishing-resistant factors over SMS or email codes.

Full defensive detail is in securing authentication. Next, see the richest takeover surface in password-reset flaws, or try an MFA bypass on a free lab.