Security guide

Why Math.random Is Not Safe for Passwords

Learn why Math.random is suitable for UI effects but not for passwords, reset codes, tokens, or other security-sensitive secrets.

Summary

Math.random() is a general JavaScript pseudo-random function. It is useful for animations, randomized UI behavior, examples, games, and simulations. It is not specified for cryptographic security and should not be used to generate passwords, reset codes, API secrets, signing keys, or recovery tokens.

The problem

A password generator needs unpredictability against an attacker, not merely values that look varied to a user. Math.random() does not provide a browser-standard cryptographic security guarantee, and implementations may differ between engines.

The safer browser option

Modern browsers provide crypto.getRandomValues() through the Web Crypto API. PwdGen uses that interface and rejection sampling, which avoids biased character selection. If that API is unavailable, the safe behavior is to stop generation and explain the compatibility requirement.

How to review a generator

Search the source for Math.random. A serious password generator should not use it for password characters. It may appear in documentation explaining why it is unsafe, but not in the generation path.

Detailed guidance

This guide focuses on why Math.random is inappropriate for passwords and secrets. It is written for developers, students, and tool users checking whether a generator uses safe randomness, so the practical goal is not to create a dramatic security claim. The goal is to choose a password habit that can survive everyday use: sign-in forms, password managers, mobile keyboards, account recovery, shared devices, and the occasional service with strange validation rules. A secure recommendation is only useful if a real person can follow it consistently.

The safest starting point is randomness plus uniqueness. Randomness means the value is selected from a large space by a cryptographically suitable random source, not invented from a birthday, a pet name, a keyboard pattern, or a favorite quote. Uniqueness means the same password is not used anywhere else. A password that is long but reused can fail quickly after one unrelated breach, while a unique random password limits the damage to the single account where it was used.

For this topic, a practical preset is crypto.getRandomValues with rejection sampling instead of Math.random. You can apply that preset with the Web Crypto API guide and then store the final value in a trusted password manager. PwdGen generates values locally in the browser with Web Crypto; the generated password is not sent to a PwdGen server. That local design reduces server-side exposure, but it does not protect against every threat. A malicious browser extension, a compromised device, a phishing page, or unsafe clipboard handling can still expose a secret after it is generated.

The most common problems to avoid are predictable pseudo-random sequences, modulo bias, custom random functions, and demo code copied into production. These problems matter because attackers rarely need to brute-force every possible password when human habits give them a shortcut. Credential stuffing, phishing, leaked password lists, and account-recovery abuse are often more realistic than a pure mathematical search. That is why the best advice combines password quality with account-level controls such as MFA, passkeys, recovery-code storage, and regular review of recovery email or phone settings.

Use this checklist when applying the recommendation:

• Do not use Math.random for passwords.
• Use Web Crypto in browsers.
• Use Node crypto or a vetted package in CLI code.
• Test for accidental fallback code.

If a website rejects the ideal setting, do not force the password into a weaker pattern by hand. Adjust one variable at a time. If symbols are rejected, keep uppercase, lowercase, and numbers enabled and increase length. If a maximum length is low, use the largest accepted length and make sure the value is unique. If a password must be read aloud, printed, or typed on a television or router screen, consider excluding confusing characters and increasing the length to compensate for the smaller alphabet.

Finally, remember the boundary of password advice. A strong password is one layer of defense, not a guarantee. It cannot make a phishing page safe, fix malware, or compensate for a service that stores credentials poorly. The useful habit is boring but durable: generate a unique value, store it safely, protect the recovery path, and replace it quickly if you suspect exposure.

A safe next step

After reading this guide, do one small account audit instead of trying to fix everything at once. Pick the account that would cause the most trouble if it were taken over, confirm that its password is unique, and check the recovery email, recovery phone, MFA method, and backup-code storage. If any part of that chain is weak, improve that part before moving to lower-risk accounts. This order keeps the work manageable and protects the accounts that attackers are most likely to use as a stepping stone. For why math.random is not safe for passwords, the best outcome is a repeatable habit: generate locally, store carefully, and avoid reuse.

Frequently asked questions

Is Math.random ever okay?

Yes, for visual effects, simulations, and ordinary UI randomness, but not for credentials or security tokens.

What should password generators use instead?

They should use a cryptographic random source such as crypto.getRandomValues() in the browser.

Does PwdGen fall back to Math.random?

No. If Web Crypto is unavailable, PwdGen shows a compatibility warning and does not generate passwords with Math.random().