Most password advice is either too vague to be useful ("make it long and complex!") or technically inaccurate. The reality is that password security has a precise mathematical foundation, and once you understand it, the rules stop feeling arbitrary.
This isn't going to be another list of tips. It's an explanation of what's actually happening when an attacker tries to crack a password — and what that means for how you should generate them.
Entropy: The Actual Measure of Password Strength§
Password strength isn't measured in stars or a colour-coded meter. It's measured in bits of entropy — a mathematically precise measure of unpredictability.
The formula:
H = L × log₂(N)
- H = entropy in bits
- L = password length
- N = size of the character set you're drawing from
Take a lowercase-only password. N = 26.
- 8 characters: 8 × log₂(26) ≈ 37.6 bits
- 12 characters: 12 × log₂(26) ≈ 56.4 bits
Now expand the character set. The full printable ASCII set has 95 characters:
- 12 characters from 95: 12 × log₂(95) ≈ 78.8 bits
That jump from 56.4 to 78.8 bits might not sound dramatic. But because entropy is exponential, 2^78.8 represents a search space about 50,000 times larger than 2^56.4.
At 100 billion guesses per second — a realistic rate for a high-end GPU cluster attacking an unsalted MD5 hash — cracking a 78-bit password would take longer than the age of the observable universe. That's not hyperbole. That's arithmetic.
How Attacks Actually Work§
Understanding attacks is what makes the entropy math meaningful.
Brute Force§
Pure brute force tries every possible combination in sequence. It's the simplest attack conceptually and the most impractical against high-entropy passwords.
| Entropy | Time at 100 billion guesses/sec |
|---|---|
| 40 bits | ~3 hours |
| 50 bits | ~130 days |
| 60 bits | ~365 years |
| 70 bits | ~375,000 years |
| 80 bits | ~384 million years |
This is why entropy above 60 bits is the practical threshold — anything above that is brute-force-resistant against plausible near-future hardware.
Dictionary Attacks§
Here's the more important attack for most real-world passwords. Dictionary attacks don't try random combinations. They use wordlists assembled from:
- Passwords leaked in historical data breaches (the RockYou list alone has 14 million entries)
- Natural language words across dozens of languages
- Common substitution patterns (pa$$w0rd, l33tsp3ak, etc.)
- Keyboard patterns (qwerty, 123456, asdf, etc.)
- Names, places, sports teams, song lyrics
The terrifying implication: P@ssw0rd! — which passes virtually every password strength meter — is in every serious cracking wordlist. It gets cracked in milliseconds. The character substitutions people think make passwords clever are exactly what attackers have precomputed.
This is why "complexity" requirements that specify "must contain a capital letter and a symbol" are somewhat misleading. They raise entropy mildly but do nothing about dictionary-based attacks on predictable patterns.
Credential Stuffing§
This one is underappreciated. If you reuse a password across multiple services, a breach at any of them compromises all of them.
Here's what happens: a service gets breached, their password database leaks. Attackers take those leaked username/password pairs and automatically try them on hundreds of other services. This is called credential stuffing. It's fully automated and runs at scale. If your email/password combination appears in any historical breach and you've reused it anywhere, it's likely already been tried against your other accounts.
Unique passwords per service is not optional if you care about security.
Rainbow Table Attacks§
Rainbow tables are precomputed tables of hash-to-password mappings. If a service stores passwords as unsalted MD5 hashes (which still happens — please don't), an attacker with a rainbow table can reverse any common password in milliseconds.
Modern systems defend against this with salting — appending a unique random value to each password before hashing, making precomputation infeasible. But plenty of older or poorly-built systems don't. If a site stores your password, you're trusting their implementation.
What "Cryptographically Secure" Random Actually Means§
There's a big difference between Math.random() and window.crypto.getRandomValues().
Math.random() is a deterministic algorithm. It's seeded — typically from the system clock — and if an attacker knows the seed, they can reconstruct every value the generator has produced. It's fine for game mechanics. It's not fine for anything security-related.
crypto.getRandomValues() draws from the operating system's entropy pool, which is fed by hardware random number generators, thermal noise, network packet timing, mouse movement, interrupt timing, and other sources of genuine physical randomness. The output cannot be predicted even with complete knowledge of prior outputs.
function generatePassword(length, charset) {
const array = new Uint32Array(length);
window.crypto.getRandomValues(array);
return Array.from(array, (val) =>
charset[val % charset.length]
).join('');
}
This is how the NexaTools Password Generator works. Every password it produces is derived from crypto.getRandomValues(). The tool itself cannot predict what it will generate next.
Passphrases — A Genuinely Good Alternative§
There's nothing wrong with random character passwords if you store them in a password manager. But if you need something you'll actually memorize — your password manager's master password, for instance — a passphrase is worth considering.
The idea: four or more random words from a large wordlist, separated by spaces or hyphens.
correct-horse-battery-staple is the famous XKCD example. Using the EFF's Diceware wordlist (7,776 words):
- 4 words: ≈ 51.7 bits of entropy
- 5 words: ≈ 64.6 bits
- 6 words: ≈ 77.5 bits
A 6-word passphrase achieves comparable entropy to a 12-character full-ASCII random password, but it's possible to actually memorize. The critical word is random — the words must be chosen randomly, not by you. "Correct horse battery staple" is now a terrible passphrase because everyone's seen it. "Windmill turnip freeway pelican jazz umbrella" is excellent.
For passwords stored in a manager, use 20+ character random passwords. For things you need to remember, use random passphrases. For the manager's master password, use a 6-word random passphrase.
The Non-Negotiable Basics§
Beyond generation, three things matter more than anything else:
Unique per service. I mentioned this in the context of credential stuffing, but it bears repeating. The effectiveness of every other security measure collapses if you reuse passwords. A single breach elsewhere compromises everything you've reused it for.
Use a password manager. You can't have unique strong passwords for every service without one. There are too many services and the passwords need to be too long to remember. Bitwarden is free and open source. 1Password is excellent if you want something more polished. KeePassXC if you want everything local.
Stop using personal information. Birthdates, names, addresses, favourite sports teams, pet names — these dramatically reduce the effective search space for targeted attacks. A determined attacker targeting you specifically will try all of these before running general wordlists.
What the Entropy Numbers Actually Recommend§
Synthesized into practical guidance:
| Scenario | Type | Target |
|---|---|---|
| Password manager master | Passphrase | 6+ random words |
| Service passwords (in manager) | Random | 20+ chars, full charset |
| Wi-Fi password you'll type | Passphrase | 5 random words |
| API keys and secrets | Random | 32+ chars |
| Anything you must memorize | Passphrase | 5–6 random words |
The NexaTools Password Generator handles random character passwords. Set it to 20 characters minimum, enable all character sets, and the entropy meter will confirm you're in safe territory. Everything runs locally — nothing is sent anywhere, nothing is logged.