Random String Security Best Practices
Random strings are critical security primitives. Used correctly, they provide unpredictable tokens that protect user sessions and authenticate API access. Used incorrectly, they create vulnerabilities attackers exploit. This guide covers essential security practices.
Use Cryptographically Secure Generators
The most critical security decision in random string generation is using a cryptographically secure random number generator (CSPRNG). This cannot be overstated: non-cryptographic generators like Math.random() have led to real security breaches in production systems.
CSPRNGs are designed specifically to resist prediction and analysis. They use entropy from sources that attackers cannot observe or control: system timings, hardware events, environmental sensors. This entropy seeds algorithms designed to be computationally infeasible to predict or reverse-engineer. Even if an attacker observes millions of random values, they cannot predict future values or determine past values.
The Web Crypto API provides crypto.getRandomValues() for browser environments. In Node.js, use crypto.randomBytes(). In Python, use secrets module (not random module). In Java, use SecureRandom. In C#, use RNGCryptoServiceProvider. Every major platform provides CSPRNG facilities—use them.
Math.random() and similar non-cryptographic generators are deterministic algorithms that produce sequences appearing random but completely predictable. They're seeded with a single value, and the entire sequence is determined by that seed. Attackers who discover or guess the seed can reproduce the entire sequence, predicting all "random" values. These generators are fine for simulations, games, or visual effects but catastrophic for security.
Real-world breaches have resulted from using weak random number generators. Session tokens generated with predictable RNGs have been exploited to hijack user sessions. Authentication tokens with insufficient randomness have enabled unauthorized access. One notable case involved ECDSA signatures with predictable randomness, allowing attackers to recover private keys. The lesson is clear: cryptographic operations demand cryptographic randomness.
Verifying your generator is secure requires checking documentation and source code. Ensure you're using the cryptographic random functions, not convenience functions that might use weaker generators. In code reviews, flag any security-sensitive random generation not using explicit CSPRNG functions. This is low-hanging fruit that prevents high-severity vulnerabilities.
Entropy Requirements
Entropy quantifies unpredictability in bits. Each bit represents a binary choice—heads or tails, 0 or 1. A string with n bits of entropy has 2^n possible values. More bits exponentially increase the number of values an attacker must try in a brute force attack.
For authentication tokens, aim for at least 128 bits of entropy. This provides 2^128 possible values (about 340 undecillion). Even at a trillion guesses per second, brute forcing 128-bit entropy would take billions of times the age of the universe. This is "computationally infeasible"—theoretically possible but practically impossible with any conceivable resources.
Session IDs should use 112-128 bits minimum. The OWASP guidance recommends at least 64 bits, but modern applications should exceed this. Session tokens are high-value targets—compromising a session token grants immediate access to a user's account. Higher entropy provides comfortable security margins.
API keys deserve even higher entropy—128-256 bits. API keys often have long lifespans and broad privileges. They might authenticate automated systems making millions of requests. The combination of long lifetime, high privilege, and automated use makes them prime targets for brute force attacks if entropy is insufficient.
Temporary codes can use less entropy if they expire quickly and have rate limiting. A 6-digit numeric code has only 20 bits of entropy (log2(1,000,000) ≈ 20). This seems dangerously low, but combined with 5-minute expiration and rate limiting after 3 failed attempts, it becomes practical. The limited time window and attempt restrictions make brute force attacks infeasible despite low entropy.
Calculating required entropy depends on attack scenarios. Consider: how many guesses can an attacker make per second? How long will the token be valid? What rate limiting is in place? If an attacker can try 1000 tokens per second for 24 hours (86,400 seconds), they can make 86.4 million attempts. To make success probability negligible, you need enough entropy that 86.4 million represents a tiny fraction of the total space. With 64 bits of entropy (2^64 ≈ 18 quintillion values), 86.4 million attempts have about 1 in 214 million chance of success.
The birthday paradox affects collision probability for identifiers. If you generate random IDs and want collision probability below 1 in a billion when you have a million IDs, you need at least 80 bits of entropy. The formula is approximately P ≈ n^2 / (2 * 2^b) where P is collision probability, n is number of IDs, and b is bits of entropy. Solve for b based on acceptable P and expected n.
Storage and Transmission
Generating secure random strings is only half the battle. How you store and transmit them determines whether they remain secure or become vulnerabilities.
Never store authentication tokens in plain text in your database. If your database is compromised, attackers immediately have all valid tokens. Instead, hash tokens before storage using a cryptographic hash like SHA-256. When verifying a token, hash the provided token and compare hashes. This way, database compromise doesn't reveal usable tokens.
For session tokens, consider using encrypted cookies rather than storing server-side. Encrypted session cookies store session data client-side, encrypted with a secret key only the server knows. This eliminates server-side storage and associated database queries. However, it requires careful implementation: use authenticated encryption (like AES-GCM), protect encryption keys carefully, and limit cookie size.
Always transmit tokens over HTTPS, never plain HTTP. HTTP transmits data in clear text, allowing network attackers to intercept tokens through man-in-the-middle attacks or passive monitoring. HTTPS encrypts communication, protecting tokens in transit. This is non-negotiable for any token used for authentication or authorization.
Include tokens in Authorization headers rather than URL parameters when possible. URLs are logged by web servers, proxy servers, and browsers. They appear in browser history and bookmarks. They're often shared when users copy-paste URLs. Putting tokens in Authorization headers keeps them out of logs and prevents accidental exposure through shared URLs.
API keys in particular should never appear in URLs or version control. Use environment variables or secure configuration management systems. Rotate API keys regularly and immediately if they might be compromised. Many security breaches occur because developers commit API keys to public GitHub repositories where automated scanners find and exploit them within minutes.
Implement token rotation for long-lived sessions. Issue short-lived access tokens (hours) and longer-lived refresh tokens (days/weeks). Clients use refresh tokens to obtain new access tokens without re-authentication. If an access token is compromised, it expires soon. Refresh tokens can be one-time-use, invalidating themselves when used to get a new access token. This limits the window of opportunity for attackers.
Monitor for suspicious token usage. Log when tokens are used, from what IP addresses, for what resources. Alert on anomalies: tokens used from multiple IPs, unusual access patterns, or failed verification attempts. Quick detection and response can limit damage from compromised tokens.
Try the Tool
Random String Generator
Related Articles
What Are Random Strings?
Random strings are sequences of characters selected unpredictably from a defined set. They're everywhere in modern software—from the session cookie in your browser to the API key for your cloud services. Understanding random strings helps you use them appropriately and securely.
Character Sets for Random Strings
The character set you choose for random strings affects entropy, compatibility, and usability. This guide helps you select appropriate character sets for different use cases.