How to compute password strength (entropy bits)
Compute password entropy in bits, average brute-force attack time, charset, dictionary/year/sequence penalties. NIST SP 800-63B compliance, bcrypt/argon2 hash.
Report a calculation error
Help us improve. Describe what is wrong with the calculation.
Result
| Voce | Valore |
|---|
Show full details
Share result
Disclaimer: this calculation is for informational purposes only. For important decisions, consult a qualified professional.
How to compute password strength: entropy in bits measures the number of attempts an attacker would need on average to guess the password with brute-force. Naive formula: H = L * log2(N), where L is password length and N is charset (26 lower + 26 upper + 10 digit + 33 ASCII symbols = 95 max). Example: 12 chars from 95 charset: H = 12 * log2(95) = 78.9 bits. However, real passwords contain common words, years, keyboard sequences that reduce effective entropy via dictionary attacks (Hashcat, John the Ripper). NIST SP 800-63B (June 2017) recommends 12+ char passphrases with dictionary blacklist, NOT forced complexity requirements. Essential tool for cybersecurity, IT, GDPR, ISO 27001, NIS2 EU compliance, FFIEC US banking.
Password entropy formulas
Naive entropy (Shannon): H = L * log2(N) bits, where L = length, N = charset size (alphabet pool to draw from). For 8-char password lowercase only (a-z, N=26): H = 8 * log2(26) = 37.6 bits. Adding upper (N=52): 8 * log2(52) = 45.6 bits. With digit+symbol (N=95): 8 * log2(95) = 52.6 bits. Length more important than complexity: 16 lower (26) = 75.2 bits > 8 mixed (95) = 52.6 bits.
Effective entropy (with penalties): password "P@ssw0rd2024" appears strong (12 char, mixed case + symbols + digits, charset 95 = 78.9 bits naive). BUT contains "password" dictionary word (-20 bits), "2024" year (-5 bits). Effective entropy ~54 bits. Hashcat with pre-computed rules (rockyou.txt + transformations) cracks in seconds. Common wordlists: rockyou, crackstation, hashes.org. Dropbox zxcvbn library computes effective entropy considering dictionaries.
Time to crack: T = (2^H / 2) / R seconds, where H entropy bits, R hashes/second rate. R varies by hash function: MD5 GPU cluster 100 billion/sec, SHA-256 single GPU RTX 4090 1 billion/sec, bcrypt cost 10 GPU 50,000/sec, argon2id moderate 1,000/sec. Example: 50 bits entropy, R=10^10/s: T = 2^49/10^10 = 56,000 sec = 15 hours. NIST recommends slow hash functions for password storage (bcrypt, argon2, PBKDF2 with 600,000+ iterations).
Recommended entropy table (NIST 2017 SP 800-63B):
- < 28 bits: very weak, crackable in seconds
- 28-36 bits: weak, crackable in hours-days
- 36-60 bits: decent, low-risk accounts
- 60-80 bits: strong, NIST acceptable for most uses
- 80-128 bits: very strong, critical accounts (banking, admin)
- >= 128 bits: AES-128 equivalent, cryptographic level
History and context
The concept of password entropy was formalized by Claude Shannon (1948) in his seminal paper "A Mathematical Theory of Communication" (Bell System Tech J), introducing the bit unit to measure information. The first famous distributed crack was DESCHALL Project (1997) which broke DES (56 bits) in 96 days with 78,000 machines. Bill Burr (NIST 2003) proposed the classic "complexity rule" (8+ chars with upper+lower+numbers+symbols, password change every 90 days) in original NIST SP 800-63, formally retired in 2017 (NIST SP 800-63B Appendix A) after evidence it generated predictable passwords (e.g., "Password1!", "Welcome123!"). XKCD strip #936 (Randall Munroe 2011) "correct horse battery staple" popularized 4-word random passphrases (44 bits + memorability). Today NIST SP 800-63B recommends: minimum 8 chars (10+ preferable), 12+ for privileged accounts, blacklist compromised passwords (HaveIBeenPwned API contains 13+ billion passwords), no forced rotation if not compromised. Dropbox zxcvbn library (2012) realistic entropy estimation. Global cybersecurity industry > $200 billion/year (2024). GDPR EU 2018, ISO 27001 information security, NIS2 EU 2024, FFIEC US banking guidelines mandate adequate password policies.
Entropy examples table (charset 95 ASCII)
- "abcd1234" (8 chars): 8*log2(36)=41 bits, 5 min GPU MD5 cracking
- "P@ssw0rd1" (9 chars): ~50 bits naive, ~30 bits effective (dictionary)
- "correct horse battery staple" (28 chars): 4-word passphrase, ~50-60 bits effective, years to crack
- "Tr0ub4dor&3" (11 chars): 65 bits naive, ~28 bits effective (XKCD parody)
- "X8sJ#kL!9P3@" (12 chars random): 78.9 bits, years to crack 10^10/s
- 16 chars random charset 95: 105 bits, billions of years
- 20 chars random charset 95: 131 bits, post-quantum safe tier 1
- 32 chars random charset 95: 210 bits, post-quantum safe tier 2
- UUID v4 random: 122 bits (session token, identifier)
- BIP-39 12-word seed: 128 bits (Bitcoin/Ethereum wallet)
Worked numerical examples
Example 1 - typical user password. "Password123!" 12 chars, charset 95. H_naive = 12*log2(95) = 78.9 bits. Penalty: "password" dictionary -20, "123" sequence -10, total -30. H_effective = 49 bits. Hashcat MD5 GPU 10^10 hash/s: 2^48/10^10 = 28,000 sec = 7.8 hours. Vulnerable. NIST SP 800-63B compliance requires 60+ bits.
Example 2 - XKCD style passphrase. "correcthorsebatterystaple" 25 chars. Naive H = 25*log2(26) = 117.5 bits. But attacker uses Diceware wordlist 7776 words (12.9 bits/word): if 4 words H_eff = 4*12.9 = 51.6 bits. Crack time 10^10/s: 2^50/10^10 = 31,500 sec = 8.7 hours. Marginal. Adding 5 words: 65 bits, 9 years. Adding random numbers/symbols in tail: 80+ bits, secure.
Example 3 - password manager generated. 1Password generates "X8sJ#kL!9P3@K2v$" 16 chars charset 95. H = 16*log2(95) = 105 bits. No penalty. Bcrypt cost 10 crack time (50,000 hash/s): 2^104/50000 = 4*10^26 sec = 13 billion years. Secure. SOC 2 compliance, GDPR Art 32 technical organizational measures.
Example 4 - 4-digit banking PIN. ATM PIN 4 digits, charset 10. H = 4*log2(10) = 13.3 bits. Crack time 10^10/s: instant. But ATM blocks after 3 attempts (rate limiting), reducing practical attacks. US banks (Chase, Wells Fargo, BofA) adopt 2FA SMS/biometrics beyond PIN per FFIEC Authentication Guidance Strong Customer Authentication.
Example 5 - enterprise vault master password. CISO at JPMorgan requires 20+ char master password for Active Directory admin: "JPM-NYC-2026-Quanto-Stelliferi-K9z!" 36 chars. Naive H = 36*log2(95) = 236 bits. Penalty: "JPM" abbreviation (-3), "NYC" toponym (-5), "2026" year (-5), total -13. H_eff = 223 bits. Very secure even post-quantum (Shor algorithm impacts asymmetric, not symmetric). ISO 27001 ISMS control A.9.4.3 password management.
Limits and considerations
- Naive entropy overestimates security for real passwords (common words, predictable leetspeak substitutions).
- zxcvbn realistic vs charset-based: 30-50 bits differences for "common" passwords.
- Slow hash function (bcrypt, argon2) crucial: MD5/SHA1 deprecated for password storage.
- Salt mandatory (16+ random bytes per password) prevents rainbow table attacks.
- Server-side rate limiting after N failed attempts nullifies online brute force.
- 2FA/MFA adds entropy-independent layer (NIST AAL2/AAL3).
- Password managers (1Password, Bitwarden, KeePass) generate unique password per service.
- HIBP (HaveIBeenPwned) database 13+ billion compromised passwords, NIST recommends check.
- Quantum computing: Grover's algorithm halves effective entropy (128 bits -> 64 bits), move to 256 bits for quantum-safe.
- Social engineering bypasses entropy: phishing, pretexting, OSINT info collection.
Common errors
- Reusing same password across multiple services (data breach contaminates all).
- Predictable leetspeak substitutions: P@ssw0rd, M3l0, h3ll0 (Hashcat has standard rules).
- Keyboard patterns: qwerty, asdf, 1qaz2wsx (in top 100 dictionary lists).
- Personal dates: kids' names + birth year (easy OSINT from Facebook, LinkedIn).
- Forced password change every 30-90 days: users write incremental variants (P1!, P2!, P3!).
- Security questions with public info ("mother's maiden name" = census).
- Saving passwords in plaintext browser/Excel/post-it (use password manager instead).
- MD5/SHA-1 hash without salt+iter (deprecated by NIST 2010).
- Truncating passwords >50 chars (some service bugs, silently reduces entropy).
- Email recovery without 2FA: email account is master key, must have maximum protection.
Practical applications
- NIST SP 800-63B: US federal standard password policy, international reference.
- GDPR EU Art 32: appropriate technical measures, robust authentication.
- ISO 27001 A.9: access control, formal password policy.
- NIS2 EU 2024: mandatory cybersecurity for critical sectors.
- FFIEC SCA: Strong Customer Authentication for US banks (knowledge+possession+inherence).
- HIBP: Have I Been Pwned API breach check.
- Password managers: 1Password, Bitwarden, KeePass, LastPass.
- 2FA/MFA: Google Authenticator, Authy, YubiKey FIDO2.
- Cryptography: AES-128/256, key derivation PBKDF2/argon2id.
- Penetration testing: Hashcat, John the Ripper, hashcat6 GPU.
Support
Questions: info@calcoi.com. Educational tool for password analysis. For professional cybersecurity applications consult NIST SP 800-63B Digital Identity Guidelines (June 2017), Schneier "Applied Cryptography" 2nd ed, Anderson "Security Engineering" 3rd ed, OWASP ASVS Application Security Verification Standard, Kerckhoffs principle.
Updated July 2026
Frequently Asked Questions
What does entropy in bits mean?
Why does length matter more than complexity?
How do dictionary attacks work?
Which hash function for password storage?
What does NIST SP 800-63B 2017 recommend?
How do password managers work?
Post-quantum cryptography impact on passwords?
Formula
H_naive = L * log2(N), L lunghezza, N charset
95 ASCII = 26 lower + 26 upper + 10 digit + 33 symbol
H_effective = H_naive - penalty (dict, year, repeat, sequence)
T = 2^(H-1) / R, R hash/sec attack speed
MD5 GPU 10^11/s, SHA-256 10^9/s, bcrypt cost 10 50000/s, argon2id 1000/s
<28 weak, 60-80 NIST acceptable, >=128 AES-128 level
Shannon 1948; NIST SP 800-63B 2017; OWASP ASVS
Comments (0)
Login to leave a comment.
No comments yet. Be the first!