Predict the next session token from the ones you can already see.
Session IDs, password-reset links, API keys and nonces are only safe if they're unpredictable. When an app generates them with a non-cryptographic generator — a language's random / mt_rand instead of a CSPRNG — the tokens look random but are fully predictable to anyone who harvests a handful and recovers the generator. Token Audit is the AT-1 weak-RNG auditorpointed at the tokens your app actually emits: it auto-decodes the encoding, recovers the generator, and predicts the next victim's token — account takeover, demonstrated.
Token Audit runs on the same rng_auditfeature entitlement as the broader RNG Auditor — gated exactly like AT-1's other licensed engines, metered per audit against your connected account. Cancel anytime in Stripe.
Launch price, set live in Stripe (changeable without redeploy). Until the price is configured the button shows Contact sales — it blocks no one.
Audits the tokens you actually emit
Point it at a sample of your real session IDs, password-reset links, API keys, voucher codes or nonces. It auto-decodes the encoding (hex / base64 / base64url), reconstructs the byte stream an attacker would harvest, and tests the generator behind it.
Predicts the next token
When the generator is weak, the auditor recovers it and predicts the NEXT token it will issue. That is the account-takeover risk made concrete — not 'this looks low-entropy' but 'here is the next user's session ID'.
Screens issuance, not just tokens
It also screens for low-entropy and DGA-style structure in host names and key issuance — the kind of generated identifiers that algorithmically-generated domains and weak key factories produce.
An honest verdict you can gate on
Every run ends in a calibrated verdict — BROKEN, WEAK, or PASS — with a non-zero exit code on weakness so it drops straight into a CI gate. A PASS means it resisted these known attacks and is incompressible to this tool, not 'provably secure'.
BROKEN: recovered the generator, predicted the next token
The classic bug is a language's everyday random / mt_rand used to mint tokens instead of a CSPRNG. From enough harvested tokens, Token Audit recovers the generator and predicts the next one it will issue. Tokens that pass an entropy spot-check still fall, because looking random and being unpredictable are not the same thing.
# a sample of session IDs your app handed out, one per line at1 token-audit scan tokens.txt --encoding hex # INPUT 4096 tokens, hex-encoded, decoded to a 32-bit value stream # ATTACK Mersenne Twister (MT19937) ... recovering internal state # recovered full state from consecutive outputs # VERDICT BROKEN (the next token is PREDICTABLE) exit 2 # EVIDENCE predicted the NEXT session ID this app will issue # REMEDIATE swap random / mt_rand for a CSPRNG (secrets / os.urandom)
Illustrative example. Sample output — not from a real run.
PASS: resists recovery
Tokens from a CSPRNG (secrets, uuid4, os.urandom) come back PASS. Read it precisely: no known attack succeeded and they're incompressible to this tool — not a proof of cryptographic security.
# the same audit against tokens drawn from a CSPRNG (secrets / uuid4) at1 token-audit scan tokens.txt # INPUT 4096 tokens, base64url, decoded to raw bytes # ATTACK MT19937 / LCG families / java.util.Random ... no recovery # VERDICT PASS (resists recovery + incompressible) exit 0 # NOTE PASS = no known attack succeeded. NOT a proof of crypto security.
Illustrative example. Sample output — not from a real run.
Three verdicts
A generator was recovered and the next token is predictable. This is a proof, not a hint — and a non-zero exit code (2) so it fails your CI build.
No full break, but the token stream is compressible — exploitable structure or DGA-style issuance, short of full recovery but well short of crypto-grade.
Resists recovery and is incompressible to this tool (exit 0). Strong evidence of soundness — not a proof of cryptographic security.
One command, drops into CI
Collect a sample of the tokens your app issues, point the scanner at the file, and let the exit code gate your build. The encoding is auto-detected.
at1 token-audit scan <file> [--encoding hex|base64|base64url] # --encoding auto-detected if omitted # exit 0 PASS — resists recovery, incompressible # exit 2 BROKEN/WEAK — a weakness was found (fail your CI build) # CI gate: non-zero exit = fix the tokens before shipping. at1 token-audit scan tokens.txt && echo "tokens OK" || echo "WEAK TOKENS"
An entropy check says it looks random. This predicts the next one.
Entropy spot-checks and generic batteries detect statistical weakness; they never recover the generator. Token Audit adds the attack that produces a prediction — and exits non-zero so your pipeline can act on it.
| Approach | Recovers generator | Predicts next token | CI gate |
|---|---|---|---|
Entropy / Shannon spot-check catches grossly low-entropy tokens, but a weak-but-uniform PRNG sails through | partial | ||
Generic randomness battery flags statistical weakness, but never recovers the generator or predicts the next token | partial | ||
Ad-hoc MT19937 cracker script can break one generator, but it's a one-off script — no encoding auto-decode, no report, no CI exit code | partial | ||
AT-1 Token Audit auto-decodes the encoding, recovers the generator, predicts the next token, and exits non-zero on weakness |
Who this is for
- Application security — catch predictable session tokens, password-reset links and nonces before an attacker harvests them.
- Platform & API teams — wire the scan into CI so a weak token generator fails the build, not production.
- Threat & SOC teams — screen for low-entropy and DGA-style host / key issuance in the wild.
- Auditors & pen-testers — hand a client a predicted next token, not an assertion that “entropy looks low”.
Part of the RNG-audit line
Token Audit is one application of the broader auditor — all on the same RNG-audit subscription.
Honest scope
A PASSmeans “resists these known attacks and is incompressible to this tool” — it is not a proof of cryptographic security. Recovery of a weak generator needs enough harvested tokens to reconstruct its state; the encoding (hex / base64 / base64url) is auto-decoded. A CSPRNG (secrets, os.urandom) correctly resists it. This is a force-multiplier for security teams, not a magic break of strong cryptography.
Running an audit is metered against a connected account on the RNG-audit subscription.