Secure Token Generator

The generator matters more than the length

A 64-character token from a weak pseudorandom source is weaker than a 16-character one from a cryptographic source. Ordinary random functions — Math.random(), rand(), most language defaults — are built for speed and statistical spread, not unpredictability. Their internal state can often be recovered from a handful of outputs, after which every future value is known. Tokens must come from a cryptographically secure source: crypto.getRandomValues() in browsers, crypto.randomBytes() in Node, secrets in Python, /dev/urandom underneath most of them.

How long is long enough

128 bits of entropy is the conventional floor for anything that must resist guessing, and 256 bits is standard for long-lived secrets. In hexadecimal that is 32 and 64 characters; in base64 roughly 22 and 43. Beyond 256 bits adds nothing useful — no attacker is brute-forcing that, and the real risks lie elsewhere.

Encoding changes the character count, not the strength

The same 16 random bytes are 32 hex characters, about 22 base64 characters, or 26 in base32. Strength is set by the byte count, not the string length. Base64url is usually the right choice for tokens appearing in URLs, since standard base64's plus and slash need escaping. Base32 is worth considering for anything a human will read aloud or retype, as it avoids visually similar characters.

Different token types have different rules

Session tokens should be long, opaque, regenerated on privilege change, and invalidated server-side at logout. Password reset tokens must be single-use and short-lived — 15 to 60 minutes — because they bypass authentication entirely. API keys are long-lived and therefore need an identifiable prefix, a revocation path and a rotation story. A prefix such as sk_live_ also lets secret scanners recognise a leaked key in a public repository, which is how a great many leaks are actually caught.

Store the hash, not the token

API keys and reset tokens should be stored hashed, exactly like passwords, so a database disclosure does not hand over working credentials. Because the token is already high-entropy random, a fast hash such as SHA-256 is sufficient — the slow key-derivation functions used for passwords exist to compensate for low entropy, which is not the problem here. Show the token once at creation and never again.

Compare in constant time

Comparing a supplied token to a stored one with an ordinary string equality can leak information through timing, since most implementations stop at the first differing byte. Use the constant-time comparison your platform provides. The attack is fiddly over a network and entirely practical locally, and the fix costs nothing.