Developer Password Generators

Every mainstream language ships two categories of random number generator: a fast, statistically-random one meant for simulations and games (random, Math.random(), java.util.Random), and a slower, cryptographically secure one meant for security-sensitive values (secrets, crypto.getRandomValues(), SecureRandom). Using the wrong one is one of the most common real-world password-generation bugs — the output looks random but can be predicted or reproduced by an attacker who knows (or guesses) the internal PRNG state or seed.

• Seeding a PRNG with a fixed or predictable value — the time, a process ID, or a hardcoded constant — defeats the purpose of generating a password at all, regardless of which language you're in.
• Applying modulo directly to a random byte or integer to pick a character index. Unless the pool size evenly divides the random source's range, this skews some characters to appear more often than others. Rejection sampling (shown in each language's example below) removes the bias.
• Logging the generated password during development and forgetting to remove it — application logs, error trackers, and debug output are not secure storage.
• Not guaranteeing at least one character from each required type when sampling purely at random from a combined pool — statistically rare failures (a password with all types enabled but zero symbols) are still possible without an explicit guarantee.