Magical 2FA Bypass: two factors in the UI, one in the API

The browser behaved correctly: it honored the flag and blocked navigation. But because the server issued the token at the same time, the entire protection depended on every client playing along voluntarily.

1. 01

   Two-step login with a short-lived challenge token

   When the second factor is enabled, the login endpoint issues only a challenge token: short-lived (about five minutes), single-use, bound to the account and the sign-in attempt, and valid for the code check only. The session token is created in the second step.

   POST /api/v5/login{ "username": "…", "password": "…" }→ 200 { "data": { "challenge_token": "ct_…", "scope": "auth:mfa_challenge", "expires_in": 300 } }POST /api/v5/login/verify-2fa{ "challenge_token": "ct_…", "totp_code": "123456" }→ 200 { "data": { "auth_token": "eyJ…", "scope": "user:authenticated" } }

2. 02

   Enforcement in gateway and middleware

   The API gateway or middleware checks the token's claims at every entry point. Protected routes accept only tokens with the user:authenticated scope; a challenge token (auth:mfa_challenge) gets 401 or 403 there. If the session token also records which factors were verified, for example in the amr claim, every service can check this on its own.

   if (!String(token.scope ?? '').split(' ').includes('user:authenticated')) {  return res.status(401).end()}const user = await users.findById(token.sub)if (user.mfaEnabled && !token.amr?.includes('otp')) {  return res.status(403).end()}

3. 03

   Automated regression tests

   End-to-end tests log in an account with an active second factor through a raw HTTP client on every login path and make sure no protected endpoint is reachable without the code. That way, a regression surfaces in the next release rather than with the next attacker.

   LOGIN_PATHS = ["/api/v5/login", "/api/v4/login"]  # every login route, incl. legacy versions@pytest.mark.parametrize("path", LOGIN_PATHS)def test_login_without_second_factor_yields_no_session(client, mfa_user, path):    r = client.post(path, json=mfa_user.credentials)    assert r.status_code == 200    data = r.json()["data"]    assert set(data) <= {"challenge_token", "scope", "expires_in"}    assert data["scope"] == "auth:mfa_challenge"    p = client.get("/api/v5/users/me/profile", headers={"Authorization": "Token " + data["challenge_token"]})    assert p.status_code in (401, 403)

Additional hardening

• Treat every login path the sameOlder API versions, mobile apps, SSO, token refresh and password reset need the same check. The OWASP guidance on MFA explicitly mentions separate APIs that users can log in through.
• Limit code attemptsStrict limits on failed code verifications prevent a six-digit code from being brute-forced.
• Keep challenge tokens narrowDiscard them after a successful check or a few failed attempts, and never accept them in place of a session token.
• Log unusual flowsSuccessful password checks without a subsequent code check, followed by access to sensitive endpoints, are a strong signal for monitoring and the SOC.
• Test endpoints in isolationPentests and API security tests should exercise authentication endpoints without the interface and inspect every response for prematurely issued tokens.

References: Multifactor Authentication Cheat Sheet (opens external website) · SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025) (opens external website) · RFC 6238: TOTP: Time-Based One-Time Password Algorithm (May 2011) (opens external website) · RFC 8176: Authentication Method Reference Values (June 2017) (opens external website)

This overview is not legal advice.