Table of Contents
The password you think is random probably is not. When people try to create passwords from memory, they fall into predictable patterns – dictionary words with numbers appended, keyboard walks like qwerty123, or personal details dressed up with symbols. Attackers know these patterns intimately, and their cracking tools are built to exploit them. A password manager solves this problem at its root by generating passwords using cryptographic randomness, producing strings that no human brain would choose and no pattern-based attack can predict.
This guide explains the mechanics behind password generation – what makes a generated password truly random, how the underlying cryptography works, and why the passwords your manager creates are orders of magnitude stronger than anything you would come up with yourself.
Why Human-Generated Passwords Fail
Before understanding how generators work, it helps to understand why they are necessary. The human brain is remarkably bad at producing randomness. When asked to pick a “random” number between 1 and 10, people overwhelmingly choose 7. When asked to create a “random” password, people do the equivalent.
Studies of breached password databases reveal consistent patterns in human-chosen passwords:
- Over 50% of passwords contain a dictionary word as their base
- Common substitutions (@ for a, 3 for e, 0 for o) appear in roughly 30% of passwords that attempt to look complex
- Sequential numbers (123, 456, 789) are appended to approximately 25% of passwords
- Birth years (1985, 1990, 2000) appear far more frequently than other four-digit combinations
- Keyboard patterns (qwerty, asdfgh, zxcvbn) rank among the top 100 most common passwords year after year
Attackers encode every one of these patterns into their cracking rules. A password like Summer2024! feels unique to the person who created it, but to a cracking algorithm running hybrid dictionary attacks, it is among the first candidates tested. The word summer is in every dictionary list, the year 2024 is a common append, and the trailing exclamation mark is the most frequently used special character.
The core problem is that humans optimize for memorability, which inherently means predictability. Password generators optimize for something completely different: entropy. To understand the full security implications of how you choose your passwords, see our guide on getting started with a password manager.
Cryptographic Random Number Generation
At the heart of every password generator is a cryptographically secure pseudorandom number generator, or CSPRNG. This is not the same as the random number generator used in video games or statistical simulations. A CSPRNG has specific properties that make it suitable for security applications.
What Makes It Cryptographically Secure
A CSPRNG must satisfy two critical requirements:
Unpredictability. Given any sequence of previously generated numbers, it must be computationally infeasible to predict the next number. An attacker who somehow observes the output of the generator should gain no useful information about future outputs.
Backtracking resistance. Even if the internal state of the generator is compromised at some point, it must be impossible to reconstruct previously generated outputs. Past passwords remain secure even if the generator’s state is later exposed.
Standard random number generators (like those used in programming languages for non-security purposes) fail both tests. They use algorithms like the Mersenne Twister, which produces statistically uniform output but is entirely predictable once enough output is observed. Using such a generator for passwords would be a critical vulnerability.
Where the Randomness Comes From
CSPRNGs need a source of true randomness – called entropy – to seed their algorithms. This entropy comes from physical phenomena that are genuinely unpredictable:
- Hardware random number generators built into modern CPUs (Intel’s RDRAND/RDSEED, AMD’s equivalent)
- Timing jitter in interrupt handling, disk I/O, and network events
- Mouse movements and keyboard timing collected by the operating system
- Thermal noise in electronic circuits
- Dedicated hardware entropy sources like the ones found in hardware security modules (HSMs)
Operating systems collect entropy from these sources into an entropy pool. On Linux, this is exposed through /dev/urandom. On Windows, the BCryptGenRandom API serves the same purpose. On macOS and iOS, SecRandomCopyBytes provides cryptographic random data.
When a password manager calls the system CSPRNG, it receives bytes that are as close to truly random as software can achieve. These bytes are then mapped to characters in the configured character set to produce the password.
The Generation Process Step by Step
Here is what happens when you click “Generate” in a password manager:
- Character set selection. Based on your settings, the generator defines the pool of available characters – lowercase letters (26), uppercase letters (26), digits (10), symbols (variable, typically 32), or a subset.
- Random byte generation. The CSPRNG produces a sequence of random bytes – one or more bytes per password character.
- Uniform mapping. Each random value is mapped to a character in the pool using an unbiased algorithm (typically rejection sampling to avoid modulo bias).
- Length fulfillment. The process repeats until the password reaches the specified length.
- Constraint validation. If rules require at least one character from each category, the generator checks and adjusts if necessary (without introducing bias in the remaining positions).
The result is a password where each character is independently and uniformly chosen from the available pool. No character is more likely than any other, no position is predictable from any other position, and no pattern exists for an attacker to exploit.
Understanding Password Entropy
Entropy is the mathematical measure of a password’s unpredictability. It is expressed in bits and calculated as the base-2 logarithm of the number of possible passwords of a given length from a given character set.
For a randomly generated password:
Entropy = log2(character_set_size ^ password_length)
Or equivalently:
Entropy = password_length x log2(character_set_size)
Here is what this looks like in practice:
| Character Set | Pool Size | Bits per Character | 12-char Entropy | 16-char Entropy | 20-char Entropy |
|---|---|---|---|---|---|
| Lowercase only | 26 | 4.7 bits | 56.4 bits | 75.2 bits | 94.0 bits |
| Lower + Upper | 52 | 5.7 bits | 68.4 bits | 91.2 bits | 114.0 bits |
| Lower + Upper + Digits | 62 | 5.95 bits | 71.4 bits | 95.3 bits | 119.1 bits |
| Full printable ASCII | 95 | 6.57 bits | 78.8 bits | 105.1 bits | 131.4 bits |
Security researchers generally recommend a minimum of 80 bits of entropy for standard accounts and 128 bits or more for high-value targets. At 128 bits of entropy, testing every possible password would require more energy than the sun produces in its entire lifetime – even with hypothetical future hardware.
The key insight is that entropy depends on both password length and character set size, but length has a larger practical impact. Doubling the character set adds one bit per character. Doubling the length doubles the total entropy. This is why a 20-character lowercase password (94 bits) can be stronger than a 12-character full-ASCII password (78.8 bits).
Character Set Selection and Trade-Offs
Password generators let you configure which character types to include. Each choice involves a trade-off between security and usability.
Lowercase and Uppercase Letters
The baseline character pool. Using both cases doubles the pool from 26 to 52 characters, adding about one bit of entropy per character. There is almost never a reason to exclude uppercase letters from generated passwords.
Digits
Adding digits expands the pool from 52 to 62 characters – a modest entropy gain. Digits are universally accepted by password fields and cause no compatibility issues.
Special Characters
Special characters (symbols like !@#$%^&*()_+-=[]{}|;:'",./<>?) can expand the pool to 95 characters. The entropy benefit per character is real but not dramatic – about 0.6 extra bits per character compared to alphanumeric only.
The trade-off is compatibility. Some websites restrict which special characters are allowed. Some reject passwords containing certain symbols, or silently truncate passwords that include them. Legacy systems, APIs, and command-line tools sometimes interpret special characters as control sequences, causing authentication failures.
A practical approach is to include common special characters (!@#$%^&*) and exclude rare ones that cause compatibility issues (\|;:'"<>). The entropy loss from a slightly smaller symbol set is negligible compared to the headaches of a password that breaks on certain platforms.
Excluding Ambiguous Characters
Many generators offer the option to exclude visually ambiguous characters: 0 vs O, 1 vs l vs I, 5 vs S. This matters if you might ever need to read or type the password manually – entering a Wi-Fi password from a printed page, for example. The entropy cost of removing a few characters from the pool is trivial.
Length Recommendations
Password length is the single most important factor in generated password strength. Here are evidence-based recommendations:
- 12 characters minimum for general online accounts. At 72+ bits of entropy with a mixed character set, this exceeds the cracking capability of any current hardware against properly hashed databases.
- 16 characters for important accounts – email, banking, cloud storage. This provides 95+ bits of entropy, offering a comfortable margin against future hardware improvements.
- 20+ characters for critical credentials like master passwords, encryption keys, and service accounts. At 120+ bits of entropy, these are effectively immune to brute force for the foreseeable future.
- No upper limit from a security perspective. Since a password manager remembers the password for you, there is no memorability cost to making it longer. A 32-character random password costs nothing in usability but provides immense security margin.
The one exception is systems that impose maximum password lengths. Some legacy systems truncate passwords silently at 16 or 20 characters. A 30-character password that gets truncated to 16 provides 16 characters of security, not 30. Check the system’s limits before relying on extreme length.
Pronounceable Passwords vs. Random Strings
Some generators offer “pronounceable” password modes – passwords that follow the phonetic patterns of natural language without being actual words. Examples might include bofuneta, crelimops, or tagnisudo.
The appeal is memorability. A pronounceable password is easier to remember and type than x7#Kp2!mR9$v. But the entropy is significantly lower because the character selection is no longer uniform – it follows syllable patterns that dramatically reduce the number of possible passwords of a given length.
A 12-character random string from a 95-character set has about 79 bits of entropy. A 12-character pronounceable password might have 40-50 bits of entropy because the character choices are constrained by phonetic rules.
For passwords that must be memorized – like a master passphrase – the passphrase approach is superior to pronounceable passwords. A passphrase like correct-horse-battery-staple uses random dictionary words, providing high entropy (roughly 13 bits per word from a standard diceware list) with much better memorability.
For passwords that the manager stores and fills automatically, there is no reason to use anything other than fully random generation. You never need to type or remember the password, so its readability is irrelevant.
What Password Managers Do That Browsers Cannot
Modern browsers have added basic password generation – Chrome and Safari can suggest random passwords for new account signups. But these built-in generators are limited in ways that matter.
Browser generators typically offer no configuration. You cannot choose the length, character composition, or format. The generated password is what the browser decides, take it or leave it. Dedicated password managers like PanicVault give you full control over every parameter, from minimum character type counts to exact length to specific character exclusions.
Browser generators also lack the auditing capabilities that make generated passwords useful over time. A dedicated manager can flag generated passwords that have appeared in known breaches, identify entries that share passwords, and prompt you to regenerate credentials for compromised services. For an in-depth comparison, see our analysis of password managers vs. browser saving.
The Math Against Attackers
To put generated password strength in perspective, consider what an attacker faces when trying to crack a randomly generated 16-character password using the full printable ASCII set (95 characters).
The search space is 95^16, which equals approximately 4.4 x 10^31 possible passwords. At a cracking speed of 10 billion hashes per second (achievable with a high-end GPU rig against fast algorithms like MD5), testing every possibility would take approximately 140 trillion years. Even with a million such rigs working in parallel, it would still take 140 million years.
Against properly implemented key derivation functions like Argon2, where each hash attempt takes hundreds of milliseconds instead of nanoseconds, the numbers become even more absurd. The password is, for all practical purposes, uncrackable through brute force.
This is the core value proposition of a password generator: it transforms password security from a human judgment problem into a math problem – and the math is overwhelmingly in the defender’s favor.
Practical Tips for Using Generated Passwords
Generate the longest password the system allows. Since the manager handles storage and filling, length costs nothing. Default to 20 characters or more.
Use the full character set unless the site restricts it. If a site rejects your generated password, reduce the symbol set rather than the length.
Regenerate after a breach notification. If a service reports a breach, generate a new password immediately. Do not modify the old one – replace it entirely.
Never modify a generated password manually. Adding a memorable word or pattern to a generated password reduces its entropy without improving anything. Trust the generator.
Store the generation date. Some managers record when a password was created. This helps you identify credentials that predate a breach disclosure and need rotation.
Generate passwords for every new account. Make it a habit. When you sign up for a new service, let the manager generate the password. There is no reason to ever choose a password yourself for a site-specific account. For a broader look at how this habit saves time in your daily workflow, see our efficiency analysis.
Conclusion
Password generators transform the hardest part of password security – creating unpredictable, high-entropy credentials – into a solved problem. By using cryptographically secure random number generators, operating on a configurable character set, and producing passwords of sufficient length, they create credentials that resist every known cracking technique by enormous margins.
Human brains are wired for patterns. Password cracking tools are built to find patterns. A generated password has no patterns to find. That is its entire strength, and it is more than enough.
Use your password manager’s generator for every account. Set the length to 16 characters or more. Include the full character set your target site supports. Let the math protect you, because it is very good at this job.
