Password Entropy Calculator
Estimate ideal entropy and keyspace for a password generator that chooses every character independently and uniformly from selected pools. Translate that mathematical space into average and worst-case offline-guess times under an explicit attack-rate scenario.
Generator model, not a password grader. Do not type a real password here. Human-chosen words, dates, keyboard paths, substitutions, reused secrets, and patterned generator output are not uniformly random and can have far less effective strength.
Ideal random-secret result
Keyspace trace
H = 20 × log₂(94) = 131.0918 bits Keyspace = 94²⁰ = 2.9011 × 10^39 Average one-secret search = keyspace ÷ (2 × 1.0000 × 10^15 guesses/s)
The number is valid only for uniform independent choices
Alphabet size
N is the number of distinct allowed characters the generator can actually choose at every position. Duplicate custom characters do not enlarge the alphabet, and a generator that favors some characters is not uniform.
Length
With independent selection and replacement, every added character multiplies keyspace by N and adds log₂N bits. Length is therefore powerful when generation is truly random and the system preserves the entire secret.
Ideal entropy
H = L log₂N measures the uncertainty of the generator distribution. It does not measure phishing resistance, database security, endpoint compromise, recovery weaknesses, reuse, or whether the user exposes the secret.
Worked example: 20 random printable ASCII characters
The selected lowercase, uppercase, digit, and symbol pools contain 26 + 26 + 10 + 32 = 94 distinct characters. A cryptographically secure generator choosing any of the 94 at each of 20 independent positions creates 94²⁰ possibilities, approximately 2.9011 × 10³⁹.
Taking base-2 logarithm gives 131.0918 bits. Each character contributes approximately 6.5546 bits. At an illustrative 10¹² guesses per second per worker and 1,000 parallel workers, the total offline rate is 10¹⁵ guesses per second.
Average time to find one specific uniformly random secret is half the keyspace divided by the effective rate, approximately 4.60 × 10¹⁶ years. Exhausting every possibility takes about 9.19 × 10¹⁶ years. These enormous figures are scenario outputs, not guarantees about a particular hash, attacker, or account.
When the attacker tests guesses against 1,000 independent accounts, the expected time to compromise any one is approximately 1,000 times shorter, about 4.60 × 10¹³ years. That multi-target opportunity reduces effective first-hit strength by log₂(1,000), about 9.97 bits, to 121.12 bits.
Human-selected passwords are not random strings
Predictable structure
People choose names, words, dates, keyboard walks, favorite teams, capitalization at the first character, digits at the end, and common substitutions. Attackers test these distributions before brute-forcing the full alphabet, so Nᴸ dramatically overstates effective strength.
Random generation
A reputable password manager can generate independent random secrets and store a unique one per account. A diceware-style passphrase can also be modeled when words are selected uniformly from a defined list using a trustworthy random process; then entropy is word count × log₂(list size).
NIST SP 800-63B-4 says estimating entropy for user-chosen passwords is challenging and uses length plus defenses such as blocklists and rate limiting instead of pretending composition rules create uniform randomness. It notes predictable user responses to required mixtures and discourages composition rules.
A strength estimator based on breached-password frequency, dictionaries, and pattern matching can be more realistic for human choices, but it still cannot know every attacker model. Treat any user-created secret as distribution-dependent and avoid assigning it the full selected-character-pool entropy.
Current NIST password guidance is broader than an entropy threshold
| SP 800-63B-4 verifier guidance | Security purpose | Relation to this calculator |
|---|---|---|
| Minimum 15 characters for a single-factor password; at least 8 when used within MFA. | Length raises guessing cost and supports usable passphrases. | The status chip checks only the 15-character single-factor length baseline, not full compliance. |
| Permit maximum length of at least 64 characters and accept broad character choices. | Allows long passwords and manager-generated secrets without needless restriction. | Larger allowed length enables more random bits; acceptance rules must preserve the secret. |
| Do not impose other composition rules. | Avoid predictable user workarounds and usability burden. | Selecting every pool is not a NIST requirement; random length is what makes this example strong. |
| Compare chosen passwords with commonly used, expected, or compromised values. | Stops common guesses likely to succeed early. | A uniform keyspace formula cannot perform breach-list screening. |
| Rate-limit failed attempts. | Constrains online guessing. | The entered offline rate intentionally represents a different breach scenario without online throttling. |
| Salt and hash with a suitable costly password hashing scheme. | Makes each offline guess more expensive and prevents shared precomputation. | Guess rate must reflect the exact KDF, cost, hardware, salt, and implementation. |
| Allow password managers, autofill, and paste. | Supports unique, random passwords and safer entry. | A manager is the practical way to realize this calculator’s uniform-random assumption. |
Online and offline guessing are different threat models
An online attacker submits guesses to a live verifier. Rate limits, lockout or authenticator disablement, bot detection, risk signals, MFA, alerts, and network latency constrain attempts. NIST describes throttling as the primary defense against online guessing and sets an upper bound for consecutive failed attempts under its scope.
An offline attacker has stolen password-verifier data and can test guesses without contacting the service. Speed depends on password-hash algorithm, work factor, memory requirement, salt, implementation, attacker hardware, parallelism, and budget. A fast unsalted hash can be attacked far faster than a well-configured memory-hard KDF.
The guess-rate field is deliberately explicit so users can run scenarios. It does not claim 10¹² guesses per second is universally correct. Benchmark the exact verifier design and apply forward-looking threat assumptions. Raising KDF cost slows both attackers and legitimate verification, so test capacity and denial-of-service risk.
Entropy does not stop phishing, malware, or reuse
- Phishing: a convincing fake site can capture even a very long password. Phishing-resistant cryptographic authenticators and passkeys bind authentication to the legitimate service.
- Malware: keyloggers, malicious browser extensions, clipboard theft, screen capture, and compromised password managers can expose secrets directly.
- Reuse: a strong password reused across sites can fall to credential stuffing after one site is breached. Every account needs a unique secret.
- Recovery: weak email recovery, security questions, help-desk social engineering, or exposed backup codes can bypass the password.
- Session theft: stolen cookies or tokens can bypass a password and MFA after authentication. Protect endpoints and sessions.
- Shoulder surfing and sharing: direct observation, messaging, spreadsheets, tickets, and plaintext notes defeat secrecy.
NIST recommends MFA, password managers, and at least 15 characters when a password is necessary. CISA emphasizes that MFA protects accounts beyond a username and password. Prefer phishing-resistant MFA or passkeys when the service supports them, especially for email, finance, administration, and password-manager vaults.
A practical password-system workflow
- Adopt passkeys or phishing-resistant MFA. Reduce dependence on knowledge-only authentication.
- Use a password manager. Generate and store a long, unique random password for every service.
- Protect the vault. Use a strong master secret, MFA, trusted devices, secure recovery, updates, and backups.
- Design the verifier well. Follow current NIST guidance for length, blocklists, rate limiting, protected transport, salt, costly hashing, and breach response.
- Model explicit threats. Separate online throttled guessing from offline hash cracking, multi-target attacks, phishing, malware, and recovery abuse.
- Monitor compromise. Detect credential stuffing, impossible travel, device changes, token theft, breached secrets, and unusual recovery.
- Respond decisively. Invalidate exposed credentials and sessions, fix the root cause, notify affected users, and rebind authenticators securely.
Frequently asked questions
Does a 20-character password always have 131 bits?
No. Only a 20-character string chosen independently and uniformly from all 94 counted characters has that ideal entropy. A quote, pattern, reused secret, or biased generator can have far less effective strength.
Do symbols automatically make a password strong?
No. Adding symbols enlarges a uniform generator’s alphabet, but predictable substitutions such as replacing “a” with “@” are tested early. Length, randomness, uniqueness, storage, verifier design, and MFA matter more than visual complexity.
Why is average cracking time half the full keyspace?
If the secret is uniformly located in a randomly ordered search, it will be found halfway through on average. An unlucky search may require nearly all guesses; a lucky one may succeed immediately.
What guess rate should I enter?
Use a measured or defensible scenario for the exact password hash, cost, attacker hardware, parallelism, and time horizon. Online login rates are constrained by verifier throttling and should not be modeled as an unrestricted offline rate.
Why do multiple accounts reduce effective bits?
An attacker testing the same candidate stream against M independent accounts has M chances for a first hit. In the ideal approximation, expected first-compromise work drops by M and effective bits drop by log₂M.
Are passphrases better than random characters?
They can be easier to enter or remember. If words are selected uniformly from a known list, entropy is easy to calculate. A human-composed sentence is not equivalent. Password managers can avoid the memorization tradeoff for most accounts.
After setting an entropy target, create a candidate with the password generator and evaluate it without entering a real credential.
References
- NIST SP 800-63B-4, Authentication and Authenticator Management
- National Institute of Standards and Technology, How Do I Create a Good Password?
- NIST Digital Identity Guidelines FAQ
- Cybersecurity and Infrastructure Security Agency, More Than a Password
Educational uniform-random model only. Never submit a real secret. Follow current authentication guidance, use unique manager-generated passwords, phishing-resistant MFA or passkeys, secure verifier storage, rate limiting, monitoring, and incident response.