Reset links must expire and be single-use

What it is

The link in a recovery mail holds the right to set a new password, not ordinary sign-in. Expiry plus single use means the token dies after a short window, and dies immediately after the first successful password change (or an explicit cancel); the same URL cannot change the password again. This entry is the lifetime of a reset token. It does not discuss magic links for sign-in, and it does not discuss kicking other sessions after a successful change—that is the next insurance step.

Why it happens

Reset links sit in inboxes, forwards, backups, and gateways longer than login links, with a larger consequence: whoever holds one may choose a new secret. Without a TTL, mail from months ago is still a key. Without single use, a forwarded copy can change the password again after a successful reset. Prefetch scanners open the link first; if the first GET burns it, the owner arrives too late. Invalidation should fall on successful change or a redeem such as “submit on the change page,” not on a landing preview. People need to see “how long is left / already used, request again,” or a dead link is read as “the account does not exist.” A newly issued link should void unused older ones so the inbox is not a ring of keys.

Studying it

Sequence tests: open after expiry, open again after a successful change, human submit after scanner prefetch.

Independent variables: TTL, invalidation trigger (GET / successful submit / new link issued), whether old tokens die when a new one is issued. Dependent variables: whether a password can still be changed after expiry or use, whether prefetch false-kills a human submit, how many live tokens sit in the inbox.

Do not substitute magic-link login experiments—the threat is the right to set a password. There is no universal TTL in hours; the window must cover mail delay without leaving change-rights overnight. Measure whether copy lets people tell “link expired” from “no such account.”

Where it stops holding

Some rules require a second factor as well; the link is only step one, and TTL still applies. A support-issued one-time code that can be submitted repeatedly is not single-use. In-app password change while signed in does not use a mail link; this entry is signed-out recovery. An everlasting short URL “so you can bookmark it” is a hole, not an accessibility feature.

Applying it

• Give reset tokens a short TTL; void them on successful submit; void old tokens when a new link is issued; keep landing preview separate from redeem.
• On expiry or prior use, say why and offer request-again, not “username or password incorrect.”
• If the person opens the page and leaves, the token still follows TTL; do not treat “viewed the page” as used unless they submitted.
• Verify: after a successful change, the same link in another browser must not change the password again. Opening after TTL must fail. A prefetching mail scanner must still leave one human submit. After a second recovery mail, the first link must be dead.

Related

• Within the group: H6.11.1 Recovery must not leak answers easier to guess than the password · H6.11.3 After reset, all existing sessions must be invalidated · H6.11.4 Recovery must not reveal whether an account exists to an unverified party
• Adjacent: H6.03 OTP and passwordless login · H6.04 Password rules
• Search terms: password reset token · single-use reset · reset link TTL