Password Reset Lab: Guess the Reset Token and Take the Admin Account

This article describes a password reset vulnerability lab where an application encodes user IDs and timestamps in base64 to create reset tokens, allowing attackers to forge valid tokens for any account including admin. The core problem is that reset tokens derived from predictable values (ID and time) with only base64 encoding provide no cryptographic security, enabling straightforward account takeover. This vulnerability matters because it demonstrates a fundamental authentication failure pattern found in real applications that OWASP classifies as a critical risk.

• How OldMail's flawed token generation worksOldMail concatenates a user's ID and the current timestamp, then base64-encodes the result to create the reset token. Base64 is encoding, not encryption—it provides no secrecy. An attacker who knows the target's ID (such as 1 for admin) and the approximate time of the reset can instantly rebuild the exact token by reconstructing the same ID+timestamp string and encoding it identically.
• Why base64 encoding creates false securityThe article explicitly states that base64 is only encoding and hides nothing—anyone can decode it instantly. A token composed of just base64-encoded ID and timestamp is fully predictable because both components are public knowledge or easily guessed. The encoding makes the token appear opaque but provides zero cryptographic protection against reconstruction.
• Attack methodology to compromise adminThe attacker first requests a password reset for their own account, decodes the base64 token to understand the ID+timestamp pattern, then triggers an admin reset and uses a nearby timestamp to construct a token for admin ID 1. The forged token is submitted to the reset endpoint, allowing the attacker to set a new admin password and gain full access. If the timestamp is slightly off, small adjustments within a range of nearby seconds will succeed.
• Why the server accepts forged tokensThe token carries no secret stored server-side that could later be verified. Since the server rebuilds the token using the same predictable derivation (ID + timestamp + base64), any token an attacker can reconstruct will be accepted as valid. The system has no way to distinguish between a legitimate token sent to the user and a forged one built by the attacker using identical logic.
• Minimum security requirements for reset tokensThe article specifies that reset tokens must contain at least 128 bits of cryptographically random data generated by a CSPRNG, never derived from ID or time. Tokens must be stored server-side as hashes tied to a single account, time-limited with a short expiry, and invalidated immediately after use or when a new reset is requested. The reset URL must be built from a trusted host and never from the incoming Host header.
• Related vulnerability: password reset poisoningA related flaw occurs when the application constructs the reset link using the incoming Host header instead of a trusted host value. An attacker can manipulate the Host header to make the reset link point to a domain they control, capturing the token when the user clicks the link. This attack is mentioned as part of the same Identification and Authentication Failures category (OWASP A07 2021).
• Real-world impact and prevalenceThe article states that weak and predictable reset tokens—using sequential IDs, timestamps, or truncated hashes—have caused real account-takeover reports across many applications. These vulnerabilities fall under OWASP Top 10 2021 Identification and Authentication Failures (A07), indicating this is a known, serious, and widespread class of vulnerability.
• Testing approach for security assessmentWhen authorized to test a reset flow, the practitioner should decode the token and inspect its contents. If base64 decoding reveals an ID, email address, or timestamp, the token is immediately identifiable as forgeable, indicating the entire reset flow is broken. The ability to decode and understand the token structure is a diagnostic step that rapidly identifies this vulnerability class.

Bottom line: Password reset tokens must be generated from cryptographically random data (minimum 128 bits from a CSPRNG) and stored server-side, never derived from predictable values like user IDs or timestamps, because any predictable component—especially those hidden only by base64 encoding—allows attackers to forge valid tokens and take over any account. Testing for this vulnerability is straightforward: decode the token, and if you see an ID or timestamp, the authentication flow is compromised.