Multi-factor authentication significantly raises the cost of account compromise. It does not eliminate it. The gap between “we have MFA” and “our MFA is implemented correctly” is where credential theft and account takeover attacks succeed — not by breaking the cryptography, but by exploiting assumptions in how MFA is integrated with the rest of the application.
This guide covers the eight bypass categories that appear most frequently in penetration test reports and bug bounty disclosures, with the implementation patterns that prevent each.
1. OTP Replay — Reusing a Valid Code
TOTP codes are time-based and single-use. If your implementation allows the same TOTP code to be submitted twice within its validity window, an attacker who intercepts or phishes the code can reuse it.
The implementation mistake: Not tracking consumed codes. The TOTP specification (RFC 6238) generates valid codes from a shared secret and the current 30-second time window. If you validate the code but do not record that it has been used, the same code passes validation again within the same window.
Fix: Maintain a short-lived consumed-code cache keyed by user ID. Redis with a 90-second TTL (covering the valid window plus one clock skew window) works well:
def validate_totp(user_id: str, code: str, secret: str) -> bool:
cache_key = f"totp:used:{user_id}:{code}"
if redis_client.exists(cache_key):
return False # replay attempt
if not pyotp.TOTP(secret).verify(code, valid_window=1):
return False
redis_client.setex(cache_key, 90, "1")
return True2. Response Manipulation — Bypassing the MFA Check Client-Side
When MFA verification is implemented with a Boolean response from the server, some applications make the authentication state decision on the client. A proxy like Burp Suite can intercept the MFA verification response and modify {"mfa_valid": false} to {"mfa_valid": true}.
The implementation mistake: Using the client-supplied result to set authentication state, rather than setting authentication state server-side on verified success and never trusting client-side signals.
Fix: After successful MFA verification, set the authenticated session flag server-side and issue a session token. The client-side code should receive only “proceed” or “failure” — never the raw Boolean that determines whether it proceeds.
// server: mfa verification endpoint
app.post('/auth/mfa/verify', async (req, res) => {
const { code } = req.body;
const session = req.session;
if (!session.pendingMfaUserId) {
return res.status(401).json({ error: 'No pending MFA session' });
}
const valid = await verifyTOTP(session.pendingMfaUserId, code);
if (!valid) {
return res.status(401).json({ error: 'Invalid code' });
}
// Only set authenticated after server-side verification
session.userId = session.pendingMfaUserId;
session.authenticated = true;
delete session.pendingMfaUserId;
return res.json({ redirect: '/dashboard' });
});3. Brute Force — Exhausting a Short Code Space
TOTP codes are 6 digits — 1,000,000 possible values. SMS OTPs are often 4 or 6 digits with even shorter validity. Without rate limiting and lockout, the code space is exhaustible.
Attack pattern: An attacker with a valid username and password tries TOTP codes systematically. At 100 requests per second, a 6-digit space is theoretically exhaustible in under three hours. In practice, 30-second windows constrain this, but without lockout the attacker gets unlimited attempts across multiple windows.
Fix: Enforce per-user rate limits on MFA submission, separate from login rate limits. Implement progressive lockout:
MFA_MAX_ATTEMPTS = 5
MFA_LOCKOUT_SECONDS = 300
def check_mfa_rate_limit(user_id: str) -> bool:
key = f"mfa:attempts:{user_id}"
attempts = redis_client.incr(key)
if attempts == 1:
redis_client.expire(key, MFA_LOCKOUT_SECONDS)
if attempts > MFA_MAX_ATTEMPTS:
return False # locked out
return TrueNotify the user by email when the threshold is crossed. Brute force against MFA is also alertable — trigger security events after three failed attempts.
4. SIM Swap Vulnerability — Trusting SMS as a Second Factor
SMS OTP is not phishing-resistant. SIM swap attacks — where an attacker socially engineers a mobile carrier into transferring a victim’s phone number to a SIM they control — give the attacker control of all SMS OTPs. This is a well-documented attack against high-value targets (executives, crypto holders, banking customers) and is outside your application’s ability to prevent.
The developer implication: SMS OTP is acceptable for low-risk applications. For applications handling financial transactions, healthcare data, or privileged access, SMS should be offered only as a fallback, never as the primary or only MFA option.
What to implement instead: TOTP authenticator apps, and WebAuthn/FIDO2 passkeys. Both are phishing-resistant in a way SMS is not. If you must support SMS, make it clear to users that TOTP is stronger, and actively migrate users toward TOTP when possible.
5. Backup Code Weaknesses — Predictable or Unlimited Recovery Codes
Backup codes are single-use codes provided to users at MFA setup for account recovery. Implementation weaknesses include: codes that are too short (4-6 characters), codes that are not one-time-use, codes stored in plaintext, or an unlimited number of codes being accepted without rate limiting.
Fix: Generate backup codes with sufficient entropy (minimum 10 characters, alphanumeric), store them hashed (bcrypt or Argon2 — same standards as passwords), enforce single-use with immediate invalidation after consumption, and rate-limit backup code attempts as aggressively as TOTP attempts.
import secrets
import bcrypt
def generate_backup_codes(count: int = 10) -> list[str]:
codes = [secrets.token_urlsafe(10) for _ in range(count)]
hashed = [bcrypt.hashpw(c.encode(), bcrypt.gensalt()).decode() for c in codes]
return codes, hashed # return plaintext once for display, store hashedInvalidate all backup codes when the user resets their MFA configuration.
6. MFA Fatigue — Push Notification Exhaustion
If your application uses push-based MFA (Duo, Microsoft Authenticator, similar) rather than TOTP, it is vulnerable to MFA fatigue attacks. The attacker obtains valid credentials, then repeatedly sends push authentication requests to the victim’s device. Many users, receiving a barrage of push notifications, eventually approve one to stop the noise — particularly late at night.
Fix: Push-based MFA providers typically offer number-matching as a countermeasure. With number matching, the push notification shows a number (e.g. “47”) that the user must match against a number displayed in the application’s login page — a step that requires the user to have access to the login page and prevents approval of phantom pushes.
Enable number matching in your push MFA provider’s administrative console. For Duo, this is the “Verified Push” feature. For Microsoft Authenticator, it is “number matching” in the Conditional Access MFA settings. Do not accept push-based MFA from vendors that do not support number matching for new deployments.
7. Post-MFA Session Fixation — Reusing a Pre-MFA Session
Session fixation in the MFA context occurs when the application uses the same session ID throughout the authentication flow: before MFA, during MFA, and after MFA completion. If an attacker can obtain a pre-MFA session ID, and the application rotates neither the session ID nor the session token at MFA completion, that pre-MFA session ID may grant post-MFA access.
Fix: Rotate the session ID at every authentication state transition — at password verification, and again at MFA verification. The session before MFA should have a different session ID than the session after MFA.
from flask import session
# After password verification
session.regenerate() # rotate session ID
session['pending_mfa_user_id'] = user.id
# After successful MFA
session.regenerate() # rotate session ID again
del session['pending_mfa_user_id']
session['user_id'] = user.id
session['authenticated'] = TrueIn Express (Node.js), use req.session.regenerate() at both transition points.
8. OAuth SSO Bypass — MFA on the App, Not the IdP
Applications that implement MFA themselves but also support OAuth or SAML SSO create a bypass path if the identity provider does not enforce MFA. A user who would face MFA prompts when logging in with username and password can switch to “Log in with Google” (or any configured IdP) and bypass the application’s MFA entirely if Google’s account has no MFA.
Fix: If SSO is offered, MFA enforcement must happen at the IdP level, not the application level. For enterprise IdPs (Okta, Azure Entra ID, Google Workspace), Conditional Access policies can require MFA for all users regardless of which application they access. Do not implement application-level MFA for SSO users — it creates false security while the IdP path remains unguarded.
Audit your OAuth/SAML application registrations to verify that MFA is required in the IdP’s policy for each application. For consumer OAuth (Google, GitHub, Apple sign-in), you cannot require MFA on the provider’s side — in this case, determine whether those accounts should have access to the same resources as enterprise SSO users, or whether their access should be scoped down.
Implementation Checklist
For each MFA-protected application:
- Consumed TOTP codes tracked and rejected on replay within the validity window
- MFA verification state set server-side; client never receives a Boolean it can manipulate
- Per-user rate limit on MFA code submission, with lockout after five failures
- SMS OTP is a fallback only for sensitive applications; TOTP or WebAuthn is primary
- Backup codes are 10+ characters, hashed at rest, single-use, rate-limited
- Push MFA has number matching enabled (if using push-based MFA)
- Session ID rotated at password verification and again at MFA completion
- SSO paths subject to IdP-level MFA enforcement, not application-level
The most impactful change for most existing applications is adding the consumed-code cache for TOTP replay (item 1) and verifying that session rotation occurs at MFA completion (item 7). Both are common omissions in applications that implemented MFA quickly without reviewing the full flow.