A password meter accepts Summer2026! as strong because it contains a capital letter, lowercase letters, digits, and punctuation. That assessment may describe compliance with a composition rule. It does not establish how an attacker would rank the password among likely guesses.
The word, year, and final punctuation follow familiar patterns. A password generated independently from a large set of possibilities can look no more complicated while being much less predictable. The relevant difference is how the secret was selected and what the attacker already knows about it.
Password entropy provides a mathematical way to describe uncertainty under a specified model. It is useful for evaluating a random generator. Applying the same calculation to a human-created string without checking the assumptions can produce a precise-looking answer to the wrong question.
Entropy Belongs to a Selection Process
In Shannon’s information theory, entropy is a property of a probability distribution. If a generator chooses uniformly from N possible outcomes, its entropy is log2(N) bits. Uniform means that each outcome has the same probability.
For independent, uniformly selected characters, a length of L from an alphabet of S symbols gives S^L possible strings and L × log2(S) bits. Independence matters: choosing the first half randomly and repeating it does not supply a second half of independent choices.
A uniformly generated four-digit PIN has 10,000 possibilities and about 13.3 bits of entropy. That describes a generation model in which leading zeroes are allowed and every PIN is equally likely. It does not describe a population of people who disproportionately choose birth years and repeated digits.
A non-uniform distribution can have Shannon entropy too, but that one number does not directly specify an attacker’s success after a given number of guesses. An attacker can try the most likely values first. Guessing resistance depends on the distribution and the information available to the attacker, rather than only on the number of strings a field could accept.
Calculate Random Generation Without Overclaiming
Consider three illustrative generators. The figures below assume unbiased selection, independent choices, and a generator whose random source is appropriate for secrets. They describe the generator’s uncertainty, not the strength of every authentication system using its output.
| Generation rule | Possible outcomes | Approximate entropy |
|---|---|---|
| Eight random lowercase letters | 26^8 | 37.6 bits |
| Sixteen random characters from 94 symbols | 94^16 | 104.9 bits |
| Six random words from a 7,776-word list | 7776^6 | 77.5 bits |
The word example assumes selection with replacement, so every draw uses the complete list. The word list can be public. Its size and the random selection process provide the uncertainty; secrecy about the list is not the source of the calculated strength.
Generator restrictions change the calculation. Requiring a particular character class, excluding ambiguous symbols, or rejecting some outputs changes the set of permitted strings and potentially its distribution. Use the generator’s actual rules rather than assigning it the largest alphabet the destination website accepts. The site accepting a symbol does not mean the generator ever selects it.
A reproducible calculation can check the arithmetic:
from math import log2
print(round(8 * log2(26), 1))
print(round(16 * log2(94), 1))
print(round(6 * log2(7776), 1))These results do not establish a universal crack time. Even for uniform selection, converting a search space into a time estimate requires an attack model, a rate of testing, and a definition of success. Under a simple exhaustive search of equally likely candidates, finding the target takes roughly half the space on average; real attacks can differ substantially.
Human Choices Need a Different Assessment
A person may choose a familiar phrase, capitalise its beginning, replace a letter with a digit, and append a symbol. Counting every position as an independent selection from a large alphabet exaggerates the uncertainty. The choices are related and often predictable.
Adding length helps when it introduces choices the attacker cannot easily predict. Appending the service name or current year to a reused base password can make the string longer while adding little protection against an attacker who recognises the scheme. A quotation or song lyric is not equivalent to randomly selecting the same number of words.
A strength estimator can use known passwords and pattern models to identify some weak choices. Treat its output as an estimate under its own model, not a measurement of the secret’s intrinsic entropy. Do not send a real password to an unfamiliar website simply to obtain a score.
The distinction also applies to information-theory language elsewhere in software. A mathematical term is useful when its quantities and assumptions are explicit. Describing a string as complex does not supply the probability distribution needed for an entropy calculation.
Online and Offline Guessing Have Different Limits
An online attacker submits guesses to a login service. Server-side rate limits, account protections, monitoring, and additional authentication factors affect how many attempts are possible and what a successful password guess achieves. A short random secret may be protected in one tightly controlled protocol while being unsuitable as an unrestricted website password.
An offline attacker has obtained password-verification data and can test guesses without sending each attempt to the service. The password-hashing scheme and its configured cost then matter. A fast general-purpose hash allows a very different testing rate from a purpose-designed password hash.
OWASP’s password-storage guidance discusses modern password hashing, including Argon2id, salts, and work factors. A unique salt prevents identical passwords from simply sharing the same stored hash and limits reuse of precomputed work. It does not make a weak password unpredictable or prevent guessing against an individual record.
Choose and review storage parameters for the service’s environment rather than copying a crack-time chart. Record the algorithm and parameter version so the system can upgrade verification data appropriately. Passwords should not be stored as plaintext or treated as ordinary recoverable application content merely because access to the database is restricted.
Reuse and Phishing Bypass the Entropy Question
A randomly generated password can be strong against guessing and still fail to protect another account if it is reused after a breach. Credential stuffing exploits known credentials rather than searching the theoretical space. Unique credentials prevent one disclosed password from being the intended password for every other service.
Phishing changes the problem again. If someone enters the correct secret into an attacker’s page, the attacker does not need to infer it from its entropy. A stronger password can still be disclosed, and some additional authentication methods can also be relayed or socially engineered.
Phishing-resistant authentication, where appropriately supported, addresses this differently by binding authentication to the legitimate service. It should not be confused with the claim that any second factor makes phishing impossible. Recovery processes, enrolled devices, and session protection still affect the account’s security.
This is why entropy should inform a password decision without becoming a complete account-risk score. The generation, storage, authentication, and recovery stages each have failure modes that the other stages do not automatically eliminate.
Use Password Rules That Support the Intended Process
NIST SP 800-63B-4 requires at least 15 characters for passwords used as a single authentication factor within its requirements, while permitting a minimum of eight when the password is only part of multi-factor authentication. It also rejects mandatory character-mixture rules and routine periodic changes, while requiring change when compromise is evident.
These are requirements for NIST’s specified digital-identity context, not a statement that every service worldwide has the same legal obligation. The useful design principle is to support length and practical password use while blocking known weak choices and responding to actual compromise.
A service should support password managers and avoid silently truncating accepted passwords. Registration, login, and password-change paths must interpret the secret consistently. A generous field limit is of little use if one component transforms or truncates the input before verification.
Recovery deserves the same care. An attacker who can reset a password through a weaker email, help-desk, or knowledge-question process may not need to guess it at all. Changes to authentication should include a review of that alternative route.
Make Randomness Practical for the Person Using It
A password manager can generate and retain independent secrets without requiring a person to memorise each one. Its usefulness depends on protecting the manager’s own access and recovery process, keeping devices secure, and using its matching and autofill behaviour thoughtfully.
A randomly generated passphrase can be appropriate when a secret must be typed or remembered. Choose the words through a documented random process rather than inventing a sentence and assigning it the word-list calculation afterwards. Published examples, including strings in this article, should never become actual passwords.
For system designers, evaluate whether users can create, store, enter, and recover credentials reliably under the intended controls. For users, unpredictable generation and uniqueness are more dependable than elaborate personal substitution rules. The entropy number is valuable when it describes that process honestly and remains connected to the way the account is actually protected.
