YanoSec
Progress0 of 152 lessons complete

Course / 09 Web security / Lesson 02 of 28

Authentication failures

Estimated time: 16 min reading · 12 min activity

A reset link can be as powerful as a password: whoever can use it may change access to the account. A reset token is a secret value issued for that limited purpose. Authentication is the process of checking an identity; a reset flow is one part of that wider process.

A token should be unpredictable, have a limited lifetime and stop working after successful use. Expiry limits time; single use limits reuse. A session is the later record of an authenticated interaction. A safe sign-in form does not compensate for a reset flow that lets an already used token work again.

Before you begin

Estimated time
16 min reading, 12 min activity. Setup and optional practice may take longer.
Where you work
Read the original fictional requests, source fragments and state tables in a current desktop or mobile browser. The required activity needs no server, database, account or installed security tool. Do not send the printed requests to any service.
Without a lab
Use the complete printed evidence to trace the data or state on paper. Write the decision, the fact supporting it and one limit of the model, then compare with the activity rubric. This does not establish live service behavior. Reading works without JavaScript. Checking requires JavaScript and a secure browser context; saving also requires usable browser storage.

After this lesson you can:

  • Separate a login, a reset token, and a later session.
  • Apply the single-use rule to the MAPLE row at 11:21.

01Example

Follow a fictional token through a successful reset and a later request. The state changes when the reset succeeds; it is not restored by the remaining lifetime.

RIVER at 15:40: reset succeeds → state used
RIVER at 15:41: another request → state still used
Expiry: 16:00
Decision: reject reuse, even before expiry.
Teaching model; no message was sent.

02One success spends the token

In the worked model, RIVER succeeds at 15:40 and is marked used. Its expiry remains 16:00, but the used mark is enough to reject another presentation. Checking only the clock misses the state change. POND illustrates a reusable contrast; its label does not mean it is a safe policy.

The server should verify the token, its account and purpose, its expiry and its unused state, then consume it as part of a successful reset. Rate limits slow guessing but cannot prove who holds a token. These fictional rows let you reason about state; they do not establish the behavior of an email system or a real account.

Follow a reset token from a successful use to a second presentation, and see that the first success uses it up.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Supplied RIVER requests

15:40 reset succeeds and spends RIVER.

Server token state

RIVER stateOriginal: usedNow: usedconsumed
ExpiryOriginal: 16:00Now: 16:00fixed

A successful reset consumes the token; remaining lifetime does not restore it.

15:40 reset succeeds and spends RIVER.

Follow the explanation

  1. 15:40 reset succeeds and spends RIVER.
  2. 15:41 reuse is rejected even though expiry is 16:00.
Read every state and value

1. 15:40 reset succeeds and spends RIVER.

Example
Supplied RIVER requests
Items
Value: used; Status: consumed · Value: 16:00; Status: fixed
Active Item
token
Event Label
15:40 reset succeeds and spends RIVER.
Visible Limit
A successful reset consumes the token; remaining lifetime does not restore it.

2. 15:41 reuse is rejected even though expiry is 16:00.

Example
Supplied RIVER requests
Items
Value: used; Status: still consumed · Value: 16:00; Status: fixed
Active Item
token
Event Label
15:41 reuse is rejected even though expiry is 16:00.
Visible Limit
A successful reset consumes the token; remaining lifetime does not restore it.
A successful reset consumes the token; remaining lifetime does not restore it.

03Read the MAPLE rows

Read the evidence before comparing your reasoning with the activity rubric.

Original fictional reset. No mail was sent. No account exists.

Rule for token RIVER:
  random value stored by the server
  expires at 16:00
  valid until its first successful use
  after that success the server marks it used

Worked trace, token RIVER:
  15:40 first use succeeds and sets a new password
  15:41 second use finds the used mark
  Decision on the card: the second use does not meet the rule

Contrast card, token POND, not used in the question:
  the same value is accepted on every visit until 16:00
  the card marks that pattern as reusable

Download the reset rules

token,time,event,state_after
RIVER,15:40,successful reset,used
RIVER,15:41,second presentation,used
MAPLE,11:20,successful reset,used
MAPLE,11:21,second presentation,used
POND,15:40,presentation,still_valid
POND,15:41,presentation,still_valid

Download the token state table

  1. Find MAPLE. Write the time of the successful reset and the state after it.
  2. Read the next MAPLE row. Write the event and the state.
  3. Check: MAPLE succeeds at 11:20 and the 11:21 presentation is a second presentation of a used token. It does not meet the single-use rule. RIVER is the worked pair.
  4. Stop. Do not send a reset mail or test an account you do not own.

04Optional challenge

Name one way a rate limit helps a login form, and one thing it does not prove. The rubric is: it can slow repeated attempts, and it does not establish identity. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Reset case A: distinct eventsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Event A: a password is checked to establish the account identity.
Event B: a random reset value authorizes one password replacement.
Event C: a later request uses an existing session to recognize the signed-in account.

Reset case B: fresh token timelineOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Token FERN: correct account and reset purpose, expires at 13:30, initially unused.
Rule: reject at or after expiry; reject once used; a successful reset marks it used immediately.
13:05: first valid presentation succeeds.
13:06: the same token is presented again.
No account exists and no reset is performed.

Reset case C: independent first presentationsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Same rule as case B; account and purpose match in all rows.
MOSS: unused; expiry 09:00; first presented at 08:59.
PINE: unused; expiry 09:00; first presented at 09:00.
ELM: used; expiry 09:10; presented at 08:58.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: separate login, reset and session roles; trace the single-use state transition; evaluate expiry and unused state together, including the exact expiry boundary.

07Common mistakes

If you apply the rule to POND, you picked the reusable contrast. The activity rows are MAPLE.

If you stop at the 16:00 expiry, you missed the used mark. A token can be inside its expiry and still be spent.

If you look for 09:00 in the file, that pair is only in the question.

References

  • PortSwigger: Authentication

    Explains the failure mechanism and prevention. Use it for further reading after reasoning from this page's original model; a topic page is not evidence that a lab was launched.

  • RFC 6265: HTTP State Management Mechanism

    The introduction. Set-Cookie stores a name and value the user agent may return later. This lesson's reset token is a server-side mark, not that cookie.