Password Entropy Explained: Why "P@ssword123" Is Not a Strong Password
Leaked password datasets still contain "123456," "password," and "qwerty" near the top. Security awareness campaigns have not changed the basic pattern: many users choose short, predictable passwords.
The problem is a misunderstanding of strength. Many users treat complexity, such as adding a ! and a capital letter, as the main defense. The metric that matters is entropy.
1. What Is Password Entropy?
Entropy, in information theory, measures unpredictability. For passwords, higher entropy means more guesses required for a brute-force attack.
The formula is: Entropy (bits) = log₂(Nˢ)
Where:
- N = the size of the character pool (26 for lowercase only, 52 with uppercase, 62 with digits, etc.)
- s = password length
So a password's entropy is determined by two things: character set size and length. And length matters exponentially more than complexity.
To build intuition: every additional character multiplies the search space by N. Adding one lowercase letter multiplies the possible combinations by 26. Adding a second multiplies by 26 again — 676 possibilities. By the time you reach 12 lowercase characters, you have 26¹² ≈ 9.5 × 10¹⁶ possible passwords. An attacker trying a billion guesses per second would need over three years to exhaust that space.
2. Crack Time Depends on the Threat Model
Let's put numbers on the board. Assume an attacker can try 1 billion guesses per second (a realistic figure for offline attacks against fast hash functions like MD5 or SHA-1, using consumer GPU hardware — a single NVIDIA RTX 4090 can compute over 160 billion SHA-1 hashes per second):
| Password | Character Pool (N) | Length (s) | Entropy | Time to Crack |
|---|
abc123 | 36 | 6 | ~31 bits | < 1 second |
P@ssw0rd | 95 | 8 | ~52 bits | ~1 hour |
Tr0ub4dor&3 | 95 | 11 | ~72 bits | ~4,000 years |
correct horse battery staple | 27 | 28 | ~133 bits | Effectively forever |
Notice: correct horse battery staple (from the famous XKCD comic) is stronger than Tr0ub4dor&3 because it is longer. Length beats character gymnastics.
The threat model matters too. An online attack (trying passwords against a live login form) is rate-limited and slow — even a moderately weak password survives because the server throttles attempts. An offline attack (cracking a stolen password hash database) has no such limit. The attacker downloads the hash file and throws GPU clusters at it. This is why database breaches are so dangerous: weak passwords fall in seconds once the hashes are offline.
3. Why Password Policies Are Often Wrong
Many corporate password policies are actively counterproductive:
- "Must include uppercase, lowercase, digit, and special character": This rule shrinks the search space. Attackers know every valid password must contain at least one of each, which eliminates large swaths of possible combinations from consideration. A constraint that reduces the set of allowed passwords is a constraint that helps the attacker.
- "Must be exactly 8 characters": At 8 characters, even with the full 95-character printable ASCII set, entropy is only ~52 bits — crackable in hours with dedicated hardware.
- "Must change every 90 days": Forced rotation leads to predictable patterns:
Spring2026! becomes Summer2026!. Users increment a digit or swap a season, and attackers model these patterns. Research from Carnegie Mellon University and others has demonstrated that mandatory password changes lead to weaker, more predictable passwords, not stronger ones.
NIST's current guidelines (SP 800-63B) explicitly recommend against these outdated practices, favoring length over complexity and eliminating forced rotation. Their key recommendations: minimum 8 characters (with a strong preference for 15+), no complexity rules, screening new passwords against known compromised password lists, and no periodic mandatory resets.
4. Four Controls That Protect Passwords
Use these controls:
- Length over complexity: A 16-character all-lowercase password (entropy ~75 bits) is stronger than an 8-character password using every symbol on the keyboard (entropy ~52 bits). Every additional character doubles the attack surface.
- Uniqueness across services: Password reuse is the #1 cause of account compromise. If Service A is breached and you reused its password on Service B, no amount of entropy saves you. Credential stuffing attacks — where attackers take leaked email/password pairs and try them on other services — are automated, relentless, and effective precisely because reuse is so common.
- A password manager: Human brains cannot generate and remember 50 unique, high-entropy passwords. A password manager generates true random strings and stores them encrypted behind a single strong master password. The cognitive burden drops from "remember 50 strong passwords" to "remember one exceptionally strong passphrase."
- Multi-factor authentication (MFA): Even if a password is compromised, MFA can block account access. A stolen password plus a required TOTP code or hardware key helps only if the attacker compromises both factors. Time-based one-time passwords (TOTP) and hardware security keys (FIDO2/WebAuthn) provide different security properties; hardware keys resist phishing in ways that TOTP codes cannot.
5. Choosing and Using a Password Manager
Password managers fall into roughly three categories. Cloud-synced managers (1Password, Bitwarden, Dashlane) store encrypted vaults on the provider's servers and sync across devices. They offer the best user experience and browser integration. Locally stored managers (KeePass, KeePassXC) keep the encrypted database on your device only — you manage sync yourself via file sharing or cloud storage. Hardware token managers (OnlyKey, Mooltipass) store credentials on a dedicated physical device.
The practical recommendation: most people should use a reputable cloud-synced manager with a strong, unique master passphrase and MFA enabled on the manager account itself. The master passphrase should be a random diceware-style sequence of 5-7 words — memorable enough to type daily, strong enough to resist offline cracking. Write it down on paper and store it somewhere physically secure as a backup.
Bitwarden and KeePass are open-source and have undergone public security audits. 1Password uses a secret key architecture that means even if their servers are breached, encrypted vaults remain protected without the per-device secret key. Evaluate based on your threat model, but using any reputable password manager is vastly better than reusing passwords.
6. How to Generate a Strong Password That's Also Memorable
The XKCD method — four random common words strung together — remains one of the best approaches:
- Pick 4-6 random words from a dictionary of ~5,000 common words.
- Each word contributes ~12 bits of entropy.
- Four words = ~48 bits with the dictionary space alone, plus more from separators and capitalization choices.
- The result: "surface-tractor-battery-window" — memorable, typeable, and mathematically formidable.
Or better yet: use a password manager's built-in generator to create a truly random 20-character string and never think about it again. The best password is the one you don't have to remember.
7. Check If Your Passwords Have Already Been Compromised
Troy Hunt's "Have I Been Pwned" (haveibeenpwned.com) lets you check whether your email address appears in known data breaches. The service also offers a password search (via k-anonymity, so your full password hash is never sent to the server) that checks whether a given password has appeared in public breach corpuses.
If a password you use has appeared in any breach, it is in attacker dictionaries. Change it everywhere you used it — not just on the breached service. Password managers with breach monitoring (many now include this feature) automate this check across your entire vault.
ToolOrbit's Password Generator creates high-entropy random passwords locally in the browser, and the Hash Generator provides SHA-256 and other digest tools when you need to verify file or data integrity.
8. The Passkey Future: What Comes After Passwords
Passkeys (FIDO2/WebAuthn) represent the industry's coordinated move beyond passwords. Under the hood, a passkey is a cryptographic key pair: a private key stored securely on your device (never sent to the server), and a public key registered with the service. Authentication happens via a local biometric or device PIN unlock that signs a challenge from the server.
The security properties are fundamentally stronger than passwords. There is no shared secret to be stolen from the server. Phishing attacks fail because the browser verifies the origin before signing — a passkey registered for accounts.google.com will not sign a challenge from accounts.goog1e.com. Credential stuffing is impossible because there are no credentials to stuff.
Passkeys are still rolling out across the ecosystem. Apple, Google, and Microsoft all support them. Major services including GitHub, Google, Amazon, and PayPal have adopted them. They are not yet universal, and edge cases around device loss and cross-platform sync are still being refined, but the direction is clear. In the meantime, use a password manager with unique random passwords and enable MFA everywhere it is offered.
Conclusion
Password strength comes from entropy, uniqueness, and account controls. "P@ssword123" is weak because it is short, predictable, and present in attacker dictionaries. Use longer random passwords, store them in a password manager, enable MFA, and never reuse the same password twice.