🧪 Labs › Authentication

🔑 Part of the Web & Bug Bounty path — module 6, Auth & Account Takeover

Taking someone's account without ever learning their password.

What it is

Account takeover is the finding that ends triage arguments, and almost none of it is guessing. The password is usually the one part of the system that was built properly. What fails is everything around it: the reset sequence, the second-factor sequence, and the question of which account a given proof of identity actually proves.

A password-reset token answers 'somebody asked for a reset'. It is only safe if the application also checks WHO they asked for — and binds the reset to that account, server-side, rather than to whichever account the final request happens to name.

Multi-factor flows fail the same way. Signing in is not one event, it is a sequence, and between the steps the session is in a half-authenticated state. If different parts of the application disagree about when a session counts as signed in, the second factor becomes optional for whichever part is more relaxed.

The common thread is ordering, not cryptography. Every individual check can be correct and the flow still broken, because the checks happen in the wrong order or consult the wrong source for the subject's identity.

How to approach it

• Map each identity flow as a state machine before testing it: registration, login, second factor, reset, email or phone change, session revocation. Write down every step and what the server accepts from you at each one.
• Run a flow to completion on an account you control first, recording every request. You cannot spot a missing binding in a flow you have not watched work.
• At each step, ask which field decides WHO this operation applies to, and whether that field came from the server's own state or from your request.
• Compare how two different protected pages treat the same half-finished session — inconsistency between routes is where second-factor gaps live.
• Check what a password change or reset does to sessions and tokens that already existed.
• Reason toward full takeover rather than stopping at an anomaly: what does this let you do to an account that is not yours?

How you'll recognise it

The tells that should make you slow down and test this class properly.

• Reset, verification and second-factor flows that take an account identifier in more than one request.
• Tokens, codes or links that are not visibly tied to a single account.
• Pages that disagree about whether a half-finished login counts as signed in.
• Email or phone change flows that do not confirm the old address.

Proving it to a triager

On a real programme the report is what gets paid. What the evidence needs to show, and what usually gets it closed.

• Take over your own second account end to end, and record every request in order.
• Name the exact ordering or binding flaw — the triager needs to see which check was missing, not just the end state.
• Severity is usually high or critical; say whether user interaction is required and how much.
• Common N/A: a takeover that needs the victim's current password or access to their inbox.

How to prevent it

• Bind a reset token to its account server-side and derive the subject from the token alone — never from a field in the confirming request.
• Make reset tokens single-use, short-lived, and invalidated by a successful reset or a password change.
• Enforce the authentication stage in one place that every protected route consults, so no route can authorise a half-authenticated session.
• Invalidate all existing sessions on password reset, password change, and second-factor enrolment changes.
• Rate-limit and lock out one-time codes, and never return them, or anything derived from them, to the requester.

More Authentication labs

• JSON Web Token Attacks — When a token's signature isn't verified properly, you can rewrite who you are.
• OAuth & Token Flows — The login dance has several moving parts — and skipping a check in any of them breaks it.

← All labs