# Predictable reset and verification tokens

Reset/verify tokens from weak PRNG, UUIDv1, short codes, or loose validation that can be guessed or reused

_Area: Web authentication and account takeover. Seen in 4 disclosed reports; 2 confirmed bounties: $5,000 and $10,000; latest 2025-08-18. Updated 2026-10-23._

## How it works
A reset or verification token is meant to be an unguessable secret proving control of an account. The assumption that breaks is that the token is unpredictable, unique per request, and bound to the specific account. When the token comes from a time-seeded PRNG, a UUIDv1 (which embeds timestamp, clock sequence and MAC), a small numeric space, or a deterministic per-identifier value, an attacker can reproduce or enumerate it. The boundary collapses because holding a guessable token is treated as proof of identity.

## Where it shows up
- Tokens built from `Random()`/`rand()`/`Math.random()` without a cryptographic source, especially time-seeded [E1](https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md).
- Tokens that look like UUIDs; check the version nibble — UUIDv1 leaks timestamp and MAC [E2](https://bugbountylibrary.com/r/blog%3Alandh-tech-blog-20230811-sandwich-attack.md).
- Pre-verification session tokens returned deterministically for a given phone number or identifier [E3](https://bugbountylibrary.com/r/h1%3A1245762.md).
- Short numeric codes (6 digits) bound to a client-supplied identifier (device_id, cookie) rather than the account [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md).

## How to review
The invariant: a token must come from a CSPRNG, be unique per request, and be bound to the specific account; validation must be an exact match against that account's state. Concrete checks: grep for `Random`/`rand`/`Math.random` in token paths and confirm the seed source [E1](https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md); inspect the UUID version nibble [E2](https://bugbountylibrary.com/r/blog%3Alandh-tech-blog-20230811-sandwich-attack.md); call the token endpoint twice for the same account and confirm the values differ [E1](https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md)[E3](https://bugbountylibrary.com/r/h1%3A1245762.md); confirm the whole token is compared, not a prefix or parsed field; confirm rate limiting is per account, not per device [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md). Storing tokens server-side and invalidating on use is best practice, not evidenced by these reports.

## Variants seen
- Time-seeded PRNG: two requests in the same millisecond yield identical tokens [E1](https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md).
- UUIDv1 tokens: bounding the victim's reset between two own resets narrows the timestamp for brute force (a timing-correlation technique, not a code exploit) [E2](https://bugbountylibrary.com/r/blog%3Alandh-tech-blog-20230811-sandwich-attack.md).
- Deterministic pre-verification session token shared across callers for one phone number [E3](https://bugbountylibrary.com/r/h1%3A1245762.md).
- 6-digit code bound to a reusable device_id, letting one device hold many valid codes at once [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md).

## Impact and severity
Account takeover in [E1](https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md)[E2](https://bugbountylibrary.com/r/blog%3Alandh-tech-blog-20230811-sandwich-attack.md)[E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md); in [E3](https://bugbountylibrary.com/r/h1%3A1245762.md) the attacker's token becomes valid once the victim enters their SMS code, so it needs victim interaction. Severity is high because the token alone grants login. It worsens when the token is bound to a reusable client identifier [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md), when the search space is small or the window long [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md), and when the endpoint signs the user in directly. [E4](https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md) is adjacent: the weakness is device-binding and per-device rate limiting rather than token generation itself.

## Evidence
- E1: https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2025-08-19-trivial-exploit-on-c-random-html.md
- E2: https://bugbountylibrary.com/r/blog%3Alandh-tech-blog-20230811-sandwich-attack.md
- E3: https://bugbountylibrary.com/r/h1%3A1245762.md
- E4: https://bugbountylibrary.com/r/blog%3Athezerohack-com-hack-instagram-again.md