Cracking a Predictable Password Reset Token
O desafio
Um link de redefinição de senha chegou com este token na URL. Parece aleatório e impossível de adivinhar. Passe-o pelos botões de decodificação - se for apenas codificado, o flag de dentro cai sozinho. Envie o flag.
O que você vai aprender
- Recognize when a token is merely encoded rather than truly random and secret
- Understand how predictable or reversible reset tokens enable account takeover
- Spot base64 and other reversible encodings by their structure and character set
- Explain why a secure reset token must be high-entropy, server-stored, compared, and expired
Habilidades testadas
Pré-requisitos
- Basic familiarity with how password reset links work
- Knowing that base64 is an encoding, not encryption
Como funciona
When you click "forgot password", the server generates a one-time token, emails you a link containing it, and later trusts whoever presents that token to reset the account. The token is the only thing standing between an attacker and the account, so its single most important property is unpredictability: it must be a long, random secret that the server stored and can compare against, and nothing else.
The token in this challenge fails that test. It looks like a meaningless jumble of letters, but the shape gives it away - it is just base64, a reversible encoding that anyone can decode with a single button, with the readable string flipped backwards to add a thin layer of obscurity. Encoding is not encryption and it is not a secret: there is no key, so the transformation runs in both directions for everyone. A token that can be unwound with two clicks carries zero entropy that an attacker does not also have.
The impact is account takeover. If reset tokens are a reversible encoding of account data - a user ID, an email, a timestamp - an attacker who sees one valid link can decode it, understand the pattern, and forge a brand-new valid token for a different account without ever receiving that victim's email. The link that "looks random" is really a public message anyone can read and rewrite.
Erros comuns
- Assuming a token is random because it looks like noise - a long string of mixed-case letters is exactly what base64 produces from ordinary text.
- Treating base64 (or hex, or URL-encoding) as a security control. These are reversible encodings with no key; they hide nothing from anyone who recognizes them.
- Adding "obfuscation" like reversing the string or layering encoders, and believing that adds real protection. Obscurity is not entropy - a few extra clicks do not stop an attacker.
- Deriving the token from predictable account data (email, sequential ID, timestamp). If the inputs are guessable, the token is forgeable.
Como se proteger
A reset token must be unguessable to anyone who does not already hold it, which means real randomness rather than a transformation of known data. Generate it from a cryptographically secure random source with enough length to make brute force hopeless, store it server-side (ideally as a hash, the same way you store passwords), and on reset look the value up and compare it against what you stored. The token should reveal nothing about the account and should never be reconstructable from the account's data.
- Generate at least 128 bits of entropy from a CSPRNG (for example a 32-byte random value), not a counter, timestamp, or encoded user field.
- Store a hash of the token, not the token itself, so a database leak does not hand out live reset links.
- Expire tokens quickly (minutes, not days) and invalidate them immediately after a single successful use.
- Rate-limit reset requests and never leak whether an email address exists.