otp-bruteforce-testinglisted

# OTP Brute-Force Testing Validate whether an OTP verification endpoint can be brute-forced: unlimited attempts, no lockout, long TTL, weak entropy, or a response oracle that reveals the correct code. Targets must be within the scope of the engagement you are authorized to test. ## When to use - Phone/email verification flows (e.g., "add phone number to profile") - MFA / 2FA challenge steps and login-by-OTP - Password reset and account recovery - Transaction confirmation (payments, withdrawals, admin actions) - Any endpoint that accepts a 4-8 digit numeric code and returns success/failure ## Core attack pattern (reference: HackerOne #3265780, CoinMate.io) 1. Trigger an OTP challenge, submit any code, and **intercept the verification request** (Burp proxy). 2. Brute-force the OTP space (100000–999999) with Burp Intruder or the bundled script. 3. Detect the valid OTP via a **response oracle** — in the CoinMate case, the response containing a valid OTP had a **Content-Length of 961 bytes** vs. ~150 for failures. 4. Replay the **original** intercepted request with the recovered OTP to complete the operation (the phone number is added to the profile). 5. Chain the impact: attacker-controlled phone number on the account → the number receives login/reset OTPs → **account takeover**. ## Phase 0 — Recon the OTP flow - Map all OTP-issuing and OTP-verifying endpoints; note parameter names (`otp`, `code`, `token`, `verificationCode`), length (4/6/8 digits), format