Random Token Generator

Tokens Created with Math.random Are a Real-World Vulnerability

This isn't a theoretical concern; it's a vulnerability that leads to actual account takeovers. `Math.random` is designed for speed, not cryptographic security. JavaScript engines use algorithms that generate a sequence of values from an internal state. Researchers have demonstrated that by observing just a few outputs, they can reconstruct this internal state and perfectly predict all subsequent values.

Imagine you generate a password reset token with `Math.random`. An attacker requests resets for their own account multiple times to gather sample tokens. They use these to reconstruct the internal state, then request a reset for an administrator's account and calculate the token that will be generated. They don't even need to intercept the email. This is why this tool exclusively uses `crypto.getRandomValues`.

How Many Bits Are Enough? A Breakdown of the Presets

A token's strength is measured by its entropy (in bits), not just its length. A 40-character token with 62 possible characters has 62^40 possible combinations, which is about 238 bits of entropy. This value is displayed in the stats below the result, along with a rating: Weak, Moderate, Strong, or Very Strong.

As a rule of thumb, session IDs should have at least 128 bits of entropy. Anything more provides little practical security benefit while making cookies longer. Conversely, anything under 40 bits is within the realm of brute-force attacks with modern hardware and should not be used for secret values.

A 6-Digit Numeric OTP Can Never Be Secure on Its Own

A 6-digit number has only one million possible combinations. An automated tool can try hundreds of combinations per second, making it possible to guess the correct one in a realistic timeframe. Increasing the number of digits isn't the answer, as users need to manually type the code they receive via text.

Therefore, the security of an OTP system comes not from the token itself, but from the rules surrounding it. The common practice in many services—a 3-minute expiry, a lock after 5 failed attempts, and rate limiting for resends—is not just a convention; it's a requirement.

• Set a short expiration time. 3-5 minutes is sufficient.
• Limit the number of attempts and invalidate the code if exceeded. The user should be forced to request a new code, not continue guessing.
• Rate-limit code generation per phone number or IP address. Otherwise, the SMS cost itself can become a denial-of-service attack vector.
• Invalidate a code immediately after it has been used.

The Real Reason for Using a Prefix

Adding a prefix like `sk_live_` to the Prefix field will prepend it to every generated token. This isn't just for aesthetics. A prefix plays two critical roles during a security incident.

First, it immediately identifies the key's origin. Discovering a mysterious 40-character string in logs or a chat history can take half a day to trace. But if it starts with `sk_live_`, you know instantly it's a production key for a specific service. Second, it enables automated detection. Tools like GitHub's secret scanning and internal commit hooks look for these fixed patterns to raise alerts. Differentiating prefixes like `live` and `test` can also prevent accidents like committing a production key into test code.

What You Do Next Is More Important

This tool does not store the tokens it generates. They are not sent to the server or saved in your browser—only settings like the preset and length are kept. If you refresh the page, the tokens will be gone, so move the values you need to a secure location immediately.

• Don't hard-code secrets into your source code. Use environment variables or a secret management tool.
• Add your `.env` file to `.gitignore`. If you've already committed it, the secret is compromised forever—deleting the file is not enough. You must revoke the key and issue a new one.
• Consider a token compromised the moment it's pasted into a chat, issue tracker, or screenshot. Even if you delete it, it may still exist in backups and email notifications.
• When storing tokens on a server, consider storing a hash of the token instead of the token itself. This way, the original token is not exposed even if the database is breached.
• Setting 'Count' to a higher number generates a list of tokens and enables 'Copy All' and 'Save' buttons. This is useful for creating keys for multiple environments at once, but your task isn't complete until you have securely deleted the saved `.txt` file.