1001Ferramentas
🔐Generators

Secure Random String Generator

Generate random strings with specific classes: lowercase, uppercase, digits, symbols. For passwords, tokens, codes. Uses crypto.getRandomValues.


  

Cryptographically secure random strings

A "secure" random string is one whose bytes come from a CSPRNG (cryptographically secure pseudo-random number generator), not from a statistical PRNG like Math.random(). The difference matters: a statistical PRNG is fast but predictable from a small amount of observed output, while a CSPRNG resists that attack. In Node use crypto.randomBytes; in browsers use crypto.getRandomValues; in Python use secrets.token_urlsafe; in PHP use random_bytes. Never roll your own.

Entropy budget: how long should the token be?

Entropy in bits is log2(charset) × length. Anything used for authentication should carry at least 128 bits of entropy — OWASP ASVS 2.6 and NIST SP 800-63B both consider 64 bits a strict floor. Quick references:

  • Hex (0-9, a-f): 4 bits per char — 32 chars = 128 bits
  • Base64url (URL-safe, no padding): ~6 bits per char — 22 chars = 132 bits
  • Base32 Crockford (no 0/O/I/L confusion): 5 bits per char — 26 chars = 130 bits
  • Alphanumeric (A-Z, a-z, 0-9): ~5.95 bits per char — 22 chars ≈ 131 bits

Typical use cases and shape

  • API key: 32-char hex (128 bits) — opaque, easy to copy
  • Session token: 40+ chars base64url stored in HttpOnly cookie
  • Magic link / password reset: 128-bit base64url with a short TTL (15-30 min) and one-shot use
  • CSRF token: per-session 128-bit value, validated on every state-changing request
  • 2FA backup codes: 16 chars grouped 4-4-4-4 for readability

Storage and comparison

Never log a full token. Treat it like a password: store a SHA-256 hash and compare with a constant-time function — crypto.timingSafeEqual in Node, secrets.compare_digest in Python, hash_equals in PHP. A naive a === b leaks the matching prefix length through timing, enabling per-character brute force. For long-lived tokens, add an expiration column and a revocation list so a stolen key can be invalidated immediately.

FAQ

Can I use a shorter token, like 8 characters? Only for non-critical things like share codes that expire in minutes. Eight alphanumeric chars is around 47 bits — brute-forceable in seconds on a modern GPU. Anything tied to a user account or money flow must clear 128 bits.

Hex or base64url — which should I pick? Prefer base64url for tokens that travel in URLs or headers because it is denser (one base64url char ≈ 1.5 hex chars at the same entropy). Hex is friendlier for humans reading logs and debugging, but ironically tokens should not be in logs at all.

Is it safe to validate a token with a regex first? For format sanity checks (length, charset), yes — it cuts down on logged garbage and obvious attacks. For the actual authentication match, no — always use a constant-time comparator after the regex passes. Doing the equality check character-by-character leaks timing.

How often should I rotate API keys? Best practice is to support rotation without rotation being mandatory: every key gets an issued-at and last-used timestamp, and the app exposes a revoke endpoint. For unattended automation, rotate at least yearly; for keys held by humans, on every team change.

Related Tools