Account Takeover
Otto's Lost Password
Otto forgets his passwords constantly, so the team built him a self-service reset. It works — a little too well. The link it mails out isn't as unguessable as everyone assumed.
This is your own sandbox with two accounts: you and otto. Request a reset for your own account and you'll see the link, just like opening your inbox. You can't read Otto's inbox — but if the way reset links are built is weak enough, you might not need to.
Take over otto, log in as him, and read the flag, in the format SPAM{this_is_an_example}. This container resets every 24 hours.
Reset endpoint: POST /api/reset with JSON
{ "username", "token", "newPassword" }.
What's the vulnerability?
- Password-reset tokens must be unpredictable. Here the token is derived only from public values — the username and the issue time.
- Anyone who sees one token (their own) learns how every token is built.
- Leaking the issue time of someone else's reset is then enough to forge their token.
Why does it matter?
A guessable reset token is a master key to every account. No password theft, no phishing — just recompute the link the system would have mailed and seize the account.
How to fix it
Generate reset tokens from a cryptographically secure random source (high entropy), store only their hash, bind them to the account, expire them quickly, and make them single-use. Never derive them from predictable data, and never leak timing.