Insecure Randomness: How to Find Predictable Reset Tokens
Security tokens must be unpredictable. When reset links, invite codes, or API keys come from timestamps, Math.random(), incremental IDs, or short numeric spaces, attackers can mint valid secrets.
This class still appears in homegrown auth and legacy PHP/Java apps.
Tokens worth inspecting
- Password reset URLs
- Email verification codes
- OAuth state / nonce values (should be strong too)
- Referral and coupon codes that unlock value
- “Unsubscribe” and magic login links
Analysis approach
- Generate several tokens for your accounts in a short window.
- Look for patterns: time correlation, monotonic sequences, low entropy length, encoded user IDs.
- Estimate search space. A 6-digit code without rate limits is a different finding than a 32-byte hex token.
- If you can predict the next token for your own account only, stop and report — do not attack other users.
Strong evidence
- Statistical bias or format that encodes
userId + timestamp - Server source map / JS showing
Math.randomfor security decisions - Ability to forge a valid reset URL for your second test account from observations on the first
Report carefully
Never demonstrate by resetting someone else’s account. Two accounts you own are enough. Include entropy estimates and recommended APIs (crypto.randomBytes, secure language equivalents).
Defensive checklist
- Use CSPRNG for all security tokens.
- Prefer long opaque tokens (128+ bits) over short numeric OTPs without strict throttling.
- Bind tokens to user ID + expiry + single use.
- Do not derive secrets from emails or sequential database IDs alone.
If you can see a pattern, an attacker can too. Measure entropy on your own tokens — that is the finding.
Original Bugflare guide informed by OWASP insecure randomness guidance.