An authentication bypass is any route to an authenticated state that skips the check the front door performs. The room teaches four of them, and the reason it is a good room is that each one fails for a different reason: one leaks information, one is unlimited, one trusts a redirected channel, and one trusts the client.
The thread worth pulling is that all four produce the same outcome. Learning to see them as variations on one decision, rather than as four unrelated tricks, is what makes the reasoning transferable to systems that look nothing like this room.
01 · Scope and authorisation
This companion documents the public TryHackMe Authentication Bypass room, a standard beginner web-security room. I worked through it in my own session. Everything below stays inside that environment, and I have published no flags, no quiz answers, no credentials, no target addresses and no copy-and-paste attack sequence. Where a technique needs a tool, I describe the decision behind using it and the flags that matter, so you can run your own test rather than replay mine.
The room covers username enumeration, credential guessing, a logic flaw in an account recovery flow, and cookie tampering, plus a short section on hashing and encoding. It maps to CWE-287, improper authentication, and touches CWE-204 observable response discrepancy, CWE-307 improper restriction of excessive authentication attempts, CWE-640 weak password recovery, and CWE-565 reliance on cookies without validation and integrity checking.
02 · Learning objectives
- Recognise authentication bypass as a class rather than a list of tricks.
- Explain why enumeration changes the economics of every later attempt.
- Describe what makes a credential guessing attempt viable, in terms of both secret strength and the absence of a limit.
- Explain how a recovery flow can be redirected by the requester.
- Explain why a client-side cookie that carries a privilege is a design failure rather than a hardening gap.
- Separate encoding from encryption without hesitating.
03 · Prerequisites and the loop I use
The room assumes basic web knowledge, an intercepting proxy, familiarity with a content discovery tool and a request tool. Nothing exotic. The loop I applied to each task is the one I use everywhere:
- Observe what the application does differently, rather than what it says.
- Hypothesise the check that is missing or misplaced.
- Choose the least invasive test that would falsify the hypothesis.
- Interpret the evidence as a property of the system, not a lucky response.
- Update the model and decide whether the finding is local or systemic.
The reason this matters here is that every task in this room is discoverable by observing differences rather than by memorising payloads. Differences are what the application cannot help revealing.
04 · The model: an identity decision has inputs, not truths
Before the tasks, build the mental model. A login form feels like a gate, but mechanically it is a comparison. The application takes an input, compares it against server-side state, and if the comparison succeeds, it grants a session. Everything a bypass does is change the inputs so that the comparison succeeds without the user knowing the secret, or remove the comparison entirely.
That gives four families, and the room's tasks map onto them neatly. Leak the input so the comparison is easy to target. Guess the input until the comparison succeeds. Redirect the channel that would deliver control of the account. Or forge the output, so no comparison happens at all.
05 · Task 2: enumeration is an information disclosure, not a guessing game
Goal. Determine whether the application tells you which accounts exist.
What to look for. A registration or signup form is the usual place, because it must validate uniqueness. If the response for an existing account differs in any way from the response for a new one, in body text, status code, response length, or even timing, the application is answering a question you did not ask. On a login form the equivalent is a difference between "no such user" and "wrong password", which hands you half the credential pair for free.
Tool choice and the flags that matter. A content discovery or request tool that can replay a request with a wordlist is right for this, because the work is volume plus comparison rather than cleverness. The flags worth understanding are the ones that let you match on status code, filter by response size, and reduce noise so the differences stand out. Do not reach for a payload list. Reach for a comparison.
Interpretation. A list of valid accounts is not a compromise. It is an intelligence gain, and its value is that it shrinks the problem. Instead of guessing a username and a password, you now have a short, verified set of usernames and a much smaller search space per account.
Failure mode and alternative. Most common mistake is treating a uniform-looking response as proof of safety. Responses can differ in length or in a single character. Compare properly, and if the responses are identical, test timing and test the same request with a definitively invalid account as a control. Without a control you cannot tell a difference from noise.
Transferable concept. Any endpoint that reports whether a resource exists is an enumeration surface. In this room it is a username. Elsewhere it is a tenant, an invoice number, a device serial or an invitation token. The question is always the same: does the application distinguish existence, and does anyone need it to?
06 · Task 3: guessing only works when the secret is weak and the attempt is unlimited
Goal. Establish whether a known account can be authenticated by trying candidate secrets.
Evidence and hypothesis. You now hold a small set of verified usernames. The hypothesis is that the authentication attempt is not limited in any meaningful way: no lockout, no meaningful delay, no difficulty challenge, no anomaly detection. Run this as a property test rather than a brute-force marathon. Send a handful of clearly wrong attempts against a known account and observe whether anything changes. If nothing changes after a reasonable number, the control is absent.
Interpretation. The finding is not "the password was weak". It is that the system permitted unlimited attempts, which converts any weak secret into a recoverable one and makes credential stuffing practical. Those are different findings with different owners. The first is a user-behaviour problem; the second is an engineering problem you can fix today.
Failure mode. Two. Committing to a large attempt volume in a lab is slow and can destabilise the target, which teaches nothing. And concluding from a single failure that the control exists. Test with a control account and note the threshold precisely, because "we have rate limiting" is meaningless without a number attached.
Transferable concept. When you report an authentication weakness, separate secret strength from attempt control. Remediation for one does not remediate the other, and conflating them lets the more fixable of the two survive in the backlog.
07 · Task 4: the recovery flow trusted the requester
Goal. Understand how a password reset can be redirected without touching the account's real mailbox.
What the flow does. A recovery flow accepts an identifier, looks up the account, and sends a token to the address on record. It is the second door to every account, and it is normally less guarded than the front one, because it is a convenience feature built by a different person at a different time.
The hypothesis to test. Ask whether the destination is ever taken from the request rather than from server-side account state. A recovery endpoint that accepts a destination field, a host header, a return path or a redirect parameter is a candidate. The test is to send the same recovery request with and without an extra field and observe whether the delivery target changes. You are looking for whether the server decides, or the requester decides.
Interpretation. If the destination can be influenced, the recovery channel is the attacker's. The token arrives where the requester chose, and possession of the token is the account. There is a second layer worth noticing: if the platform lets you register an address in the same namespace as the target, the interception becomes practical rather than theoretical, because the attacker can hold the mailbox the token lands in.
Failure mode. The mistake here is looking for an injection bug. This is not injection. Nothing is malformed, no payload is needed, and every request is valid. It is a design flaw in which an identity decision reads a value from the wrong source, and that is why it survives code review and scanners alike.
Transferable concept. For every recovery, invitation and notification flow, ask one question: is the destination derived from server state, or from the request? Any flow that answers "from the request" has delegated control of an account to whoever can send a request.
08 · Task 5: a cookie is a claim, not a state
Goal. Establish what happens when the client edits the values it is trusted to send back.
The hypothesis. If a cookie carries a statement about privilege, such as an authentication marker or a role, and the server accepts that statement without deriving it from server-side state, then the client is deciding its own authority. Test it in the least invasive way: change nothing important first, confirm the application reacts to your edit at all, then vary the value that represents privilege and observe how the application's behaviour changes.
Interpretation. This is the most instructive of the four, because the failure is conceptual rather than technical. There is no missing validation to add. The value should not have been there. A session identifier is fine in a cookie because it is a random lookup key into server state, and the server, not the client, decides what that session may do. A role or an "is authenticated" flag in a cookie inverts that relationship.
The encoding and hashing section is where most people go wrong. The room's final questions are about hashes and encodings, and the lesson is worth stating precisely. Encoding changes representation so a value can be transported, and provides no secrecy whatsoever: base64 is reversible by anyone, so a base64-encoded cookie is plain text wearing a coat. Hashing is one-way and is used to store or verify a secret, not to carry data, and a fast unsalted hash of a guessable secret is recoverable by lookup. Encryption provides confidentiality, and even a correctly encrypted client-side value is a problem if the client can replay an old one. Three different properties, three different jobs, and treating any one of them as another is a recurring cause of exactly this class of bug.
Transferable concept. The rule I use is blunt. If a value determines what the user may do, it must come from the server's own records, keyed by an opaque identifier the client cannot forge or usefully guess. If a value merely identifies which session to look up, a cookie is the right place for it.
09 · Why the chain works
The room's tasks are independent, and that is the honest way to present them: any one of them alone is enough. But there is a common structure worth naming, because it is what makes the room more than a tour of four bugs.
Authentication is a decision, and a decision can only be as good as its inputs. Enumeration improves the attacker's inputs. Unlimited guessing lets the attacker supply inputs cheaply. The recovery flaw changes where the system gets an input from. The cookie flaw removes the need for an input at all, because the client supplies the conclusion directly. Four mechanisms, one direction of travel: the attacker moves the decision away from the server's own state.
This is why the two advisories I wrote about today are worth reading alongside this room. There, a platform had a properly guarded login path and a second session path that skipped the checks entirely, which is the same failure as this room's cookie task expressed in different clothing. In both cases the system had a correct decision available and routed around it, because a second path existed that nobody compared against the first.
10 · Defensive controls, logs and detections
For each task, the control is specific, and so is the evidence it leaves. This table is the one I would take into a review.
| Weakness | Durable control | What to log and alert on |
|---|---|---|
| Username enumeration (CWE-204) | Return one identical response for every outcome: same status, same body, same timing, on registration, login and recovery alike. | Response-size and timing drift across an account set. A single request shape repeated with many identifiers. |
| Unlimited guessing (CWE-307) | Rate limit per account and per source, add progressive delay, lock or challenge after a defined threshold, and monitor for distributed attempts. | Failed-authentication counts per account and per address over short windows, and spikes in lockouts. |
| Redirectable recovery (CWE-640) | Derive the destination exclusively from server-side account state. Never accept a destination, return path or host from the request. Invalidate tokens after one use and on any credential change. | Recovery requests carrying unexpected fields, and recovery events whose destination differs from the stored address. |
| Trusted client claims (CWE-565) | Keep privilege server-side, keyed by an opaque session identifier. Mark cookies HttpOnly, Secure and SameSite. Sign or encrypt only as defence in depth, never as the trust mechanism. | Requests whose cookie values are inconsistent with server state, and role changes that appear without a corresponding administrative event. |
The third row is the one teams most often get wrong in practice, because the fix is not a validation function. It is deleting a parameter. If a recovery endpoint accepts a destination, removing that parameter entirely is the control. Anything softer leaves the decision with the requester.
11 · Misconceptions and troubleshooting
- "Base64 hides the value." It does not. It makes it transportable. If a decoded cookie reveals a privilege flag, the encoding was never protection.
- "A hash makes a cookie safe." A hash verifies integrity only if the server signs it with a key the client does not have. An unsigned hash of a guessable value is a lookup away from plain text.
- "The login is fine, so authentication is fine." The login is one path. Registration, recovery, invitations, SSO callbacks, token endpoints and remember-me flows are all paths to the same decision.
- "Different error messages are only a UX choice." They are an oracle. A distinguishing response is a measurement instrument you have handed to the attacker.
Troubleshooting the reasoning is a matter of asking the same four questions of any flow you meet. What decision is being made? Which inputs does it use? Where do those inputs come from: server state or the request? And what stops the same input being supplied a million times? Nearly every authentication weakness reduces to an uncomfortable answer to one of those four.
12 · Memory aids and practice checklist
Memory aid: leak it, guess it, redirect it, forge it. Four verbs, one outcome. If you can remember the verbs, you can reconstruct the room and, more usefully, reason about a system you have never seen.
- Enumerate every path that can reach an authenticated state, not just the login form.
- For each path, ask whether its inputs come from server state or from the request.
- Confirm that responses are indistinguishable across every outcome.
- Confirm that attempts are limited, and know the threshold as a number.
- Confirm that recovery destinations are never request-supplied.
- Confirm that privilege is server-side, and that cookies carry only opaque identifiers.
- Confirm you can tell encoding, hashing and encryption apart without pausing to think.
13 · What the room teaches
The room's lesson, stated once: authentication is a decision, and a decision is only as trustworthy as the inputs it reads. Every task shows a different way of moving that decision away from server-controlled state. That framing is what makes the room useful beyond its four techniques, because it generalises to any new flow you meet, including the ones nobody has written a room about yet.
If you want the modern version of the same reasoning applied to AI systems, the companion field note on a second session path that skipped the checks the first one ran is the direct continuation of this idea, and the RAG retrieval companion applies it to what a model is told to trust.
Frequently asked questions
What is an authentication bypass?
Any route to an authenticated state that does not verify the secret the intended login verifies. It may leak identity, guess the secret, redirect the recovery channel or trust a client-side claim. The defining property is that the system reaches its authenticated state without the check that was supposed to gate it.
Why does username enumeration matter if it does not give you a password?
Because it converts an unbounded guessing problem into a small, targeted one. It is an information disclosure that makes every later attempt cheaper, and it is cheap to fix by returning one indistinguishable response for every outcome.
Why are client-side cookies dangerous for authentication?
Because a cookie is a claim the client can edit. If the server trusts a value such as a role or an authentication marker from a cookie instead of deriving it from verified server state, then the client is deciding its own privileges. Session identifiers are safe in cookies because they are opaque lookup keys, not declarations of authority.
Is base64 encoding the same as encryption?
No. Encoding changes representation so a value can be transported and provides no secrecy, since it is trivially reversible. Encryption provides confidentiality. Hashing is one-way and is used to store or verify a secret rather than to carry data. Confusing the three is a recurring cause of authentication flaws.
Primary references and further practice
- TryHackMe: Authentication Bypass, official room
- CWE-287: Improper Authentication
- CWE-307: Improper Restriction of Excessive Authentication Attempts
- CWE-640: Weak Password Recovery Mechanism for Forgotten Password
- CWE-565: Reliance on Cookies without Validation and Integrity Checking
- OWASP Web Security Testing Guide, authentication testing chapter