Sequencer
Prove whether a session token, CSRF token, or reset code is predictable enough to forge — with the FIPS 140-2 and NIST SP 800-22 batteries.
The Sequencer answers one question: is this token random, or can you predict the next one? A session token you can guess is account takeover. A CSRF token you can forge is a bypass. A password-reset code you can predict is a hijack. Collect a sample of the token, and the Sequencer runs it through real statistical batteries to settle the verdict instead of eyeballing the hex. It is a Community tool, free in every build.
Send a flow to the Sequencer
The token you want to test already lives in a response you captured. Start from that flow.
Pick the flow that hands out the token
In History, right-click the flow whose response carries the token — the login that sets the session cookie, the page that prints a CSRF token, the endpoint that returns a reset code — and choose Capture tokens in Sequencer. Selecting the flow and pressing Cmd/Ctrl+Shift+Q does the same. The flow lands in the Sequencer's Live Capture tab, pre-filled.
Tell it where the token is
Set the token location and name (see below) so the Sequencer pulls the same value out of every response.
Collect and analyze
Set how many to collect, then Start Capture. Already have a set of tokens? Paste them under Manual Load and hit Analyze Tokens — the Authorize view can send extracted tokens straight here.
Point it at the token
Tell the Sequencer where the token sits in the response. Each capture pulls one value per response from the same place:
- Cookie — a value from
Set-Cookie(cookie:session). - Header — a response header value (
header:X-CSRF-Token). - Form field — a urlencoded field in the body (
form:authenticity_token). - Body regex — the first capture group of a regex over the body (
body:regex:"token":"([^"]+)"). - JSON path — a value at a dot-path in a JSON body (
json:data.token). - Whole body — the entire response, when the response is the token.
Not sure which value is the token? Paste a response into the candidate scan and the Sequencer ranks the high-entropy strings in it (hex, base64, JWT) by entropy, so the real token floats to the top.
Collect a sample
The batteries need volume. Two ways to feed them:
The Sequencer replays the base request over and over and extracts one token per response. Collect up to 10,000 in a run. Run up to 20 streams in parallel to gather a large sample fast, or pin every request to a single TCP connection (which forces one stream) when the token is tied to the connection or you are probing session fixation. You can also pin the transport to HTTP/1, HTTP/2, or HTTP/3 to see whether the generator behaves differently per protocol. Tokens stream in live and you can Stop at any point.
Paste a set of tokens you already have, one per line, or load them from a file. Use this for tokens you collected elsewhere, or the set handed over from Authorize.
Captured tokens stay masked in the view and in exports until you explicitly reveal them, so a live session token does not leak into a screenshot. Before the bit-level tests run, the Sequencer detects whether the tokens are hex, base64 (standard or URL-safe), or JWT and decodes them to raw bytes — so the battery measures the real randomness underneath, not the size of the encoding alphabet. For a JWT it analyzes the signature, the part that is supposed to be random.
What it measures
The Sequencer reports far more than a single entropy number:
Shannon entropy in bits per byte (0 to 8), plus the probability of each of the 8 bit positions and the per-character distribution. A bit position more than 5 % off an even 50/50 split is flagged as biased.
Monobit, poker, runs, long runs, plus a byte-distribution chi-square and a DEFLATE compression check. It runs on a fixed 2,500-byte (20,000-bit) window: the monobit count must land between 9,725 and 10,275 ones, no run of identical bits may reach 26, and the compressor must not shrink the sample by more than 3 %. Each test reports pass or fail with its value and threshold.
Frequency (block), cumulative sums (forward and backward), approximate entropy, serial, linear complexity, Maurer's universal, and random excursions. Each yields a p-value, read as a pass at the standard α=0.01 and at the stricter α=0.001. The Sequencer also reports the effective bits of real entropy per token bit at both levels — 1.0 means full entropy, 0.0 means it has collapsed.
A discrete Fourier transform test plus a peak-hunt over the byte stream. These expose a hidden cycle — a rotating counter, an epoch tick — that the bit-level tests spread thin and miss.
Per-character-position analysis flags fixed prefixes, format characters, and padding. State-machine inference builds the byte-to-byte transition table and surfaces near-deterministic transitions, the signature of a counter or weak PRNG. Cross-token correlation checks whether token N+1 follows from token N — a monotonic counter or a predictable mask lights up here.
Common prefixes and suffixes, arithmetic and embedded counters, embedded Unix timestamps, repeats, and charset restrictions (hex only, digits only). Duplicate detection reports how many tokens repeated and the most-repeated value — a duplicate session token is an immediate finding. When the tokens are JWTs, it breaks out the entropy of the header, payload, and signature separately, names the algorithm, and flags a signature with under 6 bits of entropy as suspiciously weak.
A token that looks long and random can still be weak: a timestamp plus a short counter dressed up in Base64. The structural, correlation, and pattern tests are how you prove the predictability instead of guessing at it.
Read the verdict
The results open on a Summary, with Character Analysis, Bit Analysis, and FIPS Tests tabs for the detail. The headline is one rating — Excellent, Good, Fair, Poor, or Critical — with a 0 to 100 score, the entropy figure, and every test's pass or fail.
The score is docked for low entropy, failed tests, detected patterns, bit bias, correlation, periodicity, and near-deterministic transitions. So a token that looks long and random but carries an embedded counter still rates Poor or Critical — which is exactly the token worth attacking. A test that could not run on the sample you gave it is reported as not run, never as a failure, so a large clean sample is never marked down for overflowing a fixed window.
The batteries are hungry. The FIPS window is a fixed 2,500 bytes (20,000 bits) of decoded token; the full NIST SP 800-22 battery only kicks in around 16 KB of decoded tokens. Collect a few thousand tokens for a real verdict — a handful still gives you entropy, duplicates, and pattern detection, but not the full batteries. When the decoded sample overruns the FIPS window, by default it is not squeezed in; switch the policy to test the first or last 2,500 bytes if you want the FIPS verdict on a slice as well.
Compare and export
Compare two token sets side by side: entropy difference, which set scores better, shared patterns, and the FIPS result for each. Use it to check a fix — the old generator against the new one — or to weigh two endpoints, like the login token against the reset code.
Export the full analysis as JSON (analysis, report, and a time-series breakdown) or as a Burp-compatible CSV with the per-position character-frequency table. When you capture with timing, the Sequencer also watches whether entropy drifts downward over the run and flags a generator that grows more predictable under load. Tokens stay masked in the export unless you reveal them.
Once you spot a pattern or a low-entropy position, forge a candidate token and fire it in Repeater to confirm the takeover, or sweep a range of guesses with Intruder. To take a token apart by hand first, send it to the Decoder.