A session ID needs at least 64 bits of entropy, produced by a cryptographically secure random number generator, according to the OWASP Session Management Cheat Sheet. Length only matters because it must be long enough to encode that randomness. A long but predictable ID is still weak.
Definitions
- Session ID: the token a browser sends with each request so the server knows which logged-in session it belongs to, usually in a cookie.
- Entropy: a measure of unpredictability. Each bit doubles the number of possible values, so 64 bits means 2 to the power of 64 possibilities.
- CSPRNG: a cryptographically secure pseudorandom number generator, the kind of random source built for security use and not for games or sampling.
What OWASP says
The cheat sheet states that identifiers must have at least 64 bits of entropy to prevent brute-force session guessing. It adds that a strong CSPRNG must be used so values are evenly distributed, since otherwise attackers may use statistical analysis to spot patterns. On length, it says that although length matters, entropy is what provides security, and the ID must be long enough to encode sufficient entropy. Different encodings give different lengths for the same entropy.
The same source recommends that session identifiers carry no meaning. They should not contain user names, roles or other data, and the server should hold the session state.
Turning bits into characters
Each hexadecimal character carries 4 bits, so 64 bits needs at least 16 hex characters if every character is random. Base64 style encodings carry about 6 bits per character, so fewer characters suffice. Use your framework's built-in session handling and its default random source rather than inventing your own. The cheat sheet itself recommends built-in implementations.
| Encoding | Bits per character | Characters for 64 bits of randomness |
|---|---|---|
| Hexadecimal | 4 | 16 |
| Base64 style | 6 | about 11 |
These counts assume every character comes from the random source. An ID with a fixed prefix, a timestamp or a counter has less entropy than its length suggests.
What goes wrong in real code
- IDs built from a timestamp, a user ID or an incrementing counter.
- A general-purpose random function used instead of a secure one.
- A custom session scheme that skips the framework's tested defaults.
- Reusing the same ID before and after login, which leads to session fixation.
- Putting identifiers in URLs where logs, referrers and browser history can capture them.
What a scanner can check
A scanner can collect a batch of session IDs and look for patterns: shared prefixes, sequential values, very short tokens, or tokens that decode into readable data. That catches obvious weakness. It cannot prove a generator is cryptographically secure, because a bad generator can still look random in a small sample. For that, read the code or configuration and confirm a secure random source is used.
A short checklist
- Use the framework's session management, not a custom one.
- Confirm it draws from a CSPRNG.
- Keep IDs opaque, with no user data inside.
- Regenerate the ID at login and on privilege changes.
- Set cookie flags and expiry. Our cookie security flags checklist covers that part.
- Sample IDs in a test environment and look for patterns.
Quick check
Is a 32 character session ID always secure?
No. Thirty-two characters of a predictable pattern can hold little entropy, while a shorter fully random ID can hold plenty. Check how it is generated.
Can a session ID have more than 64 bits of entropy?
Yes. 64 bits is the OWASP minimum, not a ceiling. If your framework generates longer random IDs, keep its default.
Safeguard's free scan at gold.safeguard.sh/scan can check the libraries your session handling depends on for known advisories.
Sources
Last reviewed: 19 October 2026.
