Multi-Factor Authentication

Check List

Methodology

Black Box

Manipulating OTP Verification Response

1

Register an account with a mobile number and request an OTP

2

Enter an incorrect OTP and capture the request using Burp Suite

3

Intercept and modify the server's response

4

Original response

{"verificationStatus":false,"mobile":9072346577,"profileId":"84673832"}

Change to

{"verificationStatus":true,"mobile":9072346577,"profileId":"84673832"}
5

Forward the manipulated response

6

The system authenticates the account despite the incorrect OTP

Changing Error Response To Success

1

Go to the login page and enter your phone number

2

When prompted for an OTP, enter an incorrect OTP

3

Capture the server response

{ "error": "Invalid OTP" }
4

Modify it to

{ "success": "true" }
5

Forward the response

6

If the server accepts this modification, you gain access without entering a valid OTP

OTP Verification Across Multiple Accounts

1

Register two different accounts with separate phone numbers

2

Enter the correct OTP for one account and intercept the request

3

Capture the server response and note status:1 (success)

4

Now, attempt to verify the second account with an incorrect OTP

5

Intercept the server response where the status is status:0 (failure)

6

Change status:0 to status:1 and forward the response

7

If successful, you bypass OTP authentication

OTP Bypass Using Form Resubmission In Repeater

1

Register an account using a non-existent phone number

2

Intercept the OTP request in Burp Suite

3

Send the request to Repeater and forward it

4

Modify the phone number in the request to your real number

5

If the system sends the OTP to your real number, use it to register under the fake number

Bypassing OTP With No Rate Limiting

1

Create an account and request an OTP

2

Enter an incorrect OTP and capture the request in Burp Suite

3

Send the request to Burp Intruder and set a payload on the OTP field

4

Set payload type as numbers (000000 to 999999)

5

Start the attack

6

If no rate limit is enforced, the correct OTP will eventually match

Additional OTP Bypass Test Cases

1

Default OTP Values Some applications use default OTP values such as

111111, 123456, 000000

2

Test common default values to check for misconfigurations OTP Leakage in Server Response Some applications leak OTPs in API responses Intercept OTP request responses and check if OTP is present

3

Checking if Old OTP is Still Valid Some systems allow the reuse of old OTPs Test if previously used OTPs are still accepted

Rate Limiting Attack on OTP Verification

1

Navigate to the OTP verification endpoint

https://abc.target.com/verify/phoneno
2

Enter an invalid OTP (e.g., 000000)

3

Intercept the request and send it to Intruder

4

Set the OTP field as the payload position

5

Use payload type: numbers and define a range (000000 - 999999)

6

Start the attack

7

Identify a response length change, which may indicate the correct OTP

OTP Bypassed By Using Luck Infused Logical Thinking

1

Register and Receive OTP Sign up on the target web app with your email and receive the 6-digit OTP

2

Intercept OTP Verification Request Use Burp Suite to capture the POST request containing the email and OTP payload

3

Test Invalid OTP Inputs Modify the payload by changing the OTP to a random value, deleting the OTP field, setting "otp":null, or sending an empty object

4

Send Empty OTP Payload Submit a request with the payload

{"email": "me@example.com", "otp": ""}

5

Verify Authentication Bypass Check if the server accepts the empty OTP and grants access to the account

2FA Bypass Via Parameter Tampering

1

A user would log into their Target account and enable 2FA

2

After logging out and attempting to log back in, they would be prompted for an OTP (One-Time Password)

3

Using an interception proxy like Burp Suite, the user would capture the POST request

4

Before forwarding the request, the value for the code parameter would be removed, leaving it blank

5

Upon forwarding the modified request, the server would grant access, bypassing the 2FA

Account Takeover Via Trusted-Device Session Re-Association

1

An email address owned by the attacker (e.g. attacker@example.com)

2

A victim email address that has not registered on the site (e.g. victim@example.com)

3

Clean browser session or separate browsers for attacker and victim tests

4

Target URLs

Register: https://www.example.com/account/register/

Account details: https://www.example.com/account/details/

5

Reproduction steps (precise)

6

Create attacker account

7

Visit https://www.example.com/account/register/ and register a new account using attacker@example.com

8

Complete the email OTP verification

9

During verification choose “Trust this device for 1 month” (or equivalent), creating a session that bypasses 2FA for 30 days

10

Verify you are logged in and that future logins from this device/session do not require OTP

11

Change account email to victim email

12

While still in the same session, go to https://www.example.com/account/details/

13

Change the account email from attacker@example.com to victim@example.com

14

Complete any required confirmation steps for the email change (for example, entering an OTP if requested)

15

After the change, the attacker’s current trusted session is now associated with victim@example.com

16

Confirm OTP/2FA is bypassed

17

Log out and log back in using the normal flow

18

Observe that the application does not prompt for OTP/2FA (because the session was trusted/retained)

19

This demonstrates the attacker now has an active session tied to the victim's email without the legitimate owner ever creating an account

20

Keep the bypass indefinitely

21

To persist the bypass beyond the 1-month trust window, repeat

22

a. Change the email back to the attacker’s email (attacker@example.com)

23

b. Re-verify the attacker email by completing the OTP and selecting “Trust this device for 1 month” again

24

c. Change the email back to victim@example.com and confirm

25

Each cycle re-establishes a new trusted session which the attacker then re-associates with the victim email

2FA Bypass Via Parameter Tampering

1

Enable MFA for the account (if not already)

2

Start login with username/password so that the MFA challenge page appears (e.g., SMS or email OTP)

3

Intercept the login POST request to

POST https://auth.example.com/v3/api/login

4

Inspect the JSON body and locate fields similar to

{
  "username":"you@example.com",
  "password":"YourPassword",
  "mode":"sms",
  "secureLogin": true,
  ...
}
5

Modify the request body before forwarding

Change "mode":"sms" → "mode":"email"

Change "secureLogin": true → "secureLogin": false

6

(In some implementations the exact words/values ​​may be different; change the logically equivalent fields)

7

Forward/send the modified request

8

The client will be logged into the account without providing the MFA code

2FA Bypass Via Session Coning

1

In a controlled and authorized testing environment (e.g., a test account or a program that permits testing), log into the target account and open account settings

2

Enable Two-Factor Authentication (2FA) and complete the setup (enter authenticator app code or SMS code) so that 2FA is active on the account

3

Log out of the account

4

Log back in using valid credentials (username/password)

5

When prompted, enter the valid 2FA code and complete the login so a new session is established

6

Using a cookie management/export tool (for example a Cookie Editor extension, the browser devtools, or a proxy tool that exposes cookies), export the session cookies for that logged-in session and copy the full cookie values

7

Open a different browser or a separate browser profile that is not currently logged into the account (or use a separate device/environment)

8

Import/paste the copied cookies into that other browser/profile using the same cookie names and values you extracted in step 6 (or overwrite the existing cookies via devtools)

9

Refresh the site or navigate to the account dashboard in the second browser

10

Observe that you can access the account content without being prompted for the 2FA code — the session cookies allowed access and 2FA was bypassed

11

(Optional) For verification, invalidate or log out the original session in the first browser and check whether the cookie-based session in the second browser still grants access

Email‑Based 2FA Reset Race Condition

1

Log into your account and enable Two-Factor Authentication (2FA)

2

Log out of your account

3

Log back in, enter your username and password, but do not enter your TOTP code

4

Click on “Reset two-factor authentication” and confirm the action by pressing OK

5

You will receive an email from the platform that contains an option to cancel the 2FA reset request

6

Do not interact with the email — do not open it or click any links

7

Wait for one full day (24 hours) without taking any action

8

After a day, return to the site and log in again

9

You will notice that 2FA has been automatically disabled, allowing you to log in successfully without providing a 2FA code — meaning an attacker could fully take over the victim’s account if the victim doesn’t cancel the request in time

2FA Race Condition (Authentication Bypass Via a Temporary-Session-Token Race / TOCTOU)

1

Target an application that uses a GraphQL API with Two-Factor Authentication (2FA) enabled

2

Analyze the login flow and confirm it has two steps

3

Step 1 Send username and password → the server responds with “2FA required” and issues a temporary session token

4

Step 2 Send the 2FA code along with that token for verification

5

Identify the race window between Step 1 and Step 2 — the temporary token becomes active before the 2FA verification is completed

6

Exploit this timing issue by sending two nearly simultaneous requests

7

Request A: The valid 2FA code submission (legitimate step)

8

Request B: An authenticated GraphQL query such as

{ me { email } }
9

using the same temporary session token from Step 1

10

Use a tool like curl or a Python script (with threading or asynchronous requests) to fire both requests at the same time, ensuring that Request B reaches the server before Request A completes

11

If the race condition succeeds, the server will return sensitive user data (e.g., email) from Request B, even though 2FA verification is not finished

12

This demonstrates a 2FA Authentication Bypass caused by improper state management during the authentication flow

13

Repeat multiple times to confirm timing consistency and determine the reliability of the race condition

Response Manipulation

1

Log into the test account, enable Two-Factor Authentication (2FA) in account settings, then log out

2

Now enable your proxy and turn on interception. In the 2FA entry form enter a random/invalid code and submit the request

3

In the proxy locate the 2FA verification request/response. The server response typically contains JSON or a flag such as { "ready": false } indicating 2FA is not yet confirmed

4

Edit the response body: change the relevant field from false to true — e.g. modify { "ready": false } to { "ready": true } (or the equivalent boolean field present in the real API response)

5

Forward the modified response back to the client

6

Refresh/wait for redirect — you should be taken to the dashboard and gain account access without providing a valid 2FA code, demonstrating a 2FA bypass

7

Repeat multiple times to confirm reproducibility and success rate. Clean up the test account or disable 2FA afterwards

Status Code Manipulation

1

Change the HTTP status code from a 4xx (indicating authentication failure) to a 200 OK status code to see if it allows access. This can trick the system into thinking the authentication was successful

2

Original Response

HTTP/1.1 401 Unauthorized
Content-Type: application/json 

{ 
"error": "Invalid credentials" 
}// Some code
3

Edited Response

HTTP/1.1 200 OK
Content-Type: application/json

{
"error": "Invalid credentials"
}

2FA Code Leakage In Response

1

Check the response of the 2FA Code Triggering Request to see if the 2FA code is leaked in the response body. If it is, it could be used to authenticate without going through the proper 2FA process

2
HTTP/1.1 200 OK
Content-Type: application/json

{
"message": "Authentication successful",
"2fa_code": "123456"
}

2FA Code Reusability

1

Generate a 2FA code and use it for authentication. Attempt to reuse the same 2FA code in a different session. Successful reuse may indicate a security vulnerability

2
POST /authenticate
Content-Type: application/json

{
"username": "user123",
"2fa_code": "123456"
}

JS File Analysis

1

Assume you are testing a web application, and you suspect that a JavaScript file may contain information about the 2FA implementation

2

Request

GET /path/to/suspected-js-file.js HTTP/1.1
Host: example.com
3

Response

HTTP/1.1 200 OK
Content-Type: application/javascript

Sample JavaScript file This file may contain information about the 2FA implementation

4

var twoFactorEnabled = true

var twoFactorMethod = "SMS"

5

You can then further analyze the JavaScript code to determine if there are any vulnerabilities or issues related to the 2FA implementation

Lack of Brute-Force Protection

1

Exploit the absence of rate limiting on the 2FA API to brute-force the 2FA code. Try various codes until you find the correct one. You can use Burps Suite’s Intruder tool for the same

2
POST /2fa
Content-Type: application/json

{
"username": "user123",
"2fa_code": "123456"
}

Missing 2FA Code Integrity Validation

1

Exploit the absence of code integrity validation to check if you can use the same 2FA code for another user’s 2FA validation

2
POST /authenticate
Content-Type: application/json

{
"username": "user123",
"2fa_code": "123456"
}

CSRF On 2FA Disabling

1

Take advantage of the absence of CSRF protection to disable 2FA without the user’s knowledge

2
POST /disable-2fa
Content-Type: application/json

{
"disable": true
}

Bypass 2FA Using The “Remember Me” Functionality

1

Attempt to bypass 2FA by using the “remember me” functionality, which may store 2FA information in a cookie, session, local storage, or IP address

2
POST /authenticate
Content-Type: application/json

{
"username": "user123",
"remember_me": true
}

2FA Refer Check Bypass

1

Navigate to an authenticated page and, if unsuccessful, change the Referer header to the 2FA page URL to trick the application into thinking the request came after satisfying 2FA

2
GET /authenticated-page
Referer: https://example.com/2fa

Sequential OTP Number

1

Check if the OTPs generated are sequential, allowing you to predict the next OTP. This can be exploited if the system generates predictable OTPs

2

Valid OTP Request 1

POST /request-otp
Content-Type: application/json

{
"2fa": "500060"
}
3

Valid OTP Request 2

POST /request-otp
Content-Type: application/json

{
"2fa": "500061"
}

Remove The OTP Parameter

1

Attempt to bypass 2FA by removing the OTP parameter from the request

2

Original Request

POST /validate-otp 
Content-Type: application/json 

{ 
"email": "user@email.com",
"2fa": "500061" 
}
3

Modified Request

POST /validate-otp 
Content-Type: application/json 

{ 
"email": "user@email.com"
}

Manipulate The OTP Parameter Values

1

Try various manipulations of the OTP parameter to see if you can bypass 2FA

2
POST /validate-otp 
Content-Type: application/json 
{
    "2fa": "123456", // make it "2fa": ""
    "2fa": "123456", // make it "2fa": "null"
    "2fa": "123456", // make it "2fa": "true"
    "2fa": "123456", // make it "2fa": null
    "2fa": "123456", // make it "2fa": "00000"
}

Password Reset/Email Change Disable 2FA

1

After resetting the user’s password or changing their email, the 2FA might automatically be disabled, which could be exploited

2FA Code Validity

1

Request multiple 2FA codes, and check if previously requested 2FA codes can be used to authenticate

2

Request for MFA Code, wait for a longer time, and try using the same code; successful use may indicate a security vulnerability

2FA Bypass Via Race Condition

1

Begin the login flow for the test account: submit username/password and reach the step where the service indicates “2FA required.” The server should issue a temporary session token/JWT and present the OTP entry page

2

Using your proxy, intercept the OTP verification request to the server. Instead of forwarding it normally, drop the request or cut the connection just before the verification response is received—simulating a network failure or the user closing the tab at the moment of verification

3

Without completing the OTP round-trip, manually navigate back to the site (e.g., homepage or dashboard) in the browser and check whether the session appears authenticated. If you are logged in, the token/session was activated too early and 2FA has been bypassed

4

If successful, inspect proxy logs/history to confirm whether an Authorization header (e.g., a Bearer token) was present/activated before OTP verification completed. (Do this only in a test environment and do not publish real token values)

5

To demonstrate impact, use the current token/session to call authenticated API endpoints and perform high-impact actions (view email, change settings, invoke sensitive endpoints) to show full account access is possible without 2FA

6

After the vendor patches the main UI flow, re-test by attempting the same bypass and also by calling backend API endpoints (e.g., direct /api/v2/* endpoints) to see if any endpoints were missed by the patch—testing for incomplete fixes

7

Repeat the sequence multiple times with varied timing to map the race window and determine reliability

8

Collect non-sensitive evidence (sanitized logs, video of the flow without revealing real tokens/OTPs) and submit a responsible disclosure report. Clean up afterwards by invalidating sessions or removing the test account

White Box

Cheat Sheet

PreviousWeaker Authentication in Alternative ChannelNextBroken Authorization

Last updated