Password Strength and Entropy: What Crack-Time Estimates Mean

Why length × log2(pool) overrates most passwords, how zxcvbn counts guesses instead, what the four attack speeds represent, and what NIST SP 800-63B-4 now asks for.

2026-10-29 · 10 min read

Every password meter gives you a verdict, but they often disagree. One site calls P@ssw0rd123 strong because it has an uppercase letter, a digit and a symbol; another calls it weak. The difference comes down to one question: is the meter counting characters, or counting guesses? This article explains both approaches, what the crack-time figures in the Password Strength Checker actually mean, and what current NIST guidance asks of passwords.

The textbook entropy formula and why it overrates passwords

The formula most people learn treats a password as a string of independent random characters. If each character comes from a pool of N symbols and the password is L characters long, there are N^L possible passwords, so the entropy in bits is:

H = L × log2(N)

The pool sizes are easy to remember:

By this formula P@ssw0rd123 has 11 characters from a pool of 95, so about 72 bits. That would take longer than the age of the universe to brute force at any realistic speed. Yet it is one of the first few thousand guesses any cracking tool tries.

The formula is correct, but only for passwords that really were chosen at random, character by character, from the whole pool. A password generator produces such passwords. People do not. People start with a word, capitalise the first letter, swap a for @ and o for 0, and add a year or 123 at the end. An attacker who knows this does not search the whole space of 95^11 strings. They search the much smaller space of words with common decorations, and they search it in order of popularity.

So the textbook figure is an upper bound. It tells you how strong the password could be if it were random. It says nothing about how strong it is.

Counting guesses instead: how zxcvbn works

In 2016 Daniel Lowe Wheeler of Dropbox published "zxcvbn: Low-Budget Password Strength Estimation" at USENIX Security. The idea is to model the attacker rather than the alphabet. The estimator asks: if an attacker tries the most likely passwords first, roughly how many guesses before they reach this one?

To answer, zxcvbn looks for every pattern it knows inside the password:

• Dictionary words from ranked lists: leaked passwords, common English words, Wikipedia words, first names and surnames. A word's rank is roughly how many guesses it costs. password is rank 2.
• Variations of those words: reversed, l33t substitutions such as @ for a, capitalisation. Each variation multiplies the guesses by a small factor, not by the full pool size.
• Keyboard walks such as qwerty, asdfgh or zxcvbn itself, using adjacency graphs for common layouts.
• Sequences such as abcdef or 9876.
• Repeats such as aaaa or abcabc.
• Dates and years, including recent years such as 2024.
• Brute force for whatever is left over, using the character pool.

It then finds the way of covering the whole password with these pieces that minimises the total number of guesses, and reports that number. The Password Strength Checker uses zxcvbn-ts 3, a maintained TypeScript version with about 49,000 leaked passwords in its list and keyboard graphs for QWERTY, QWERTZ, AZERTY, Dvorak and keypads.

Taking log2 of the guess count gives a realistic entropy in bits that you can compare with the textbook figure. The gap is often enormous:

Two things stand out. First, decorations barely help: Tr0ub4dor&3 is one uncommon word with predictable substitutions, so it costs less than a million guesses. Second, length does help, a lot, even when every piece is an ordinary word. Four words separated by spaces beat the disguised word by fourteen orders of magnitude. That is the point of the famous xkcd comic, and zxcvbn reproduces it from first principles.

Even the random 16-character string scores 53 bits rather than 105. zxcvbn charges each character it cannot explain at a flat 10 guesses (its brute-force cardinality constant), so 16 random characters count as 10^16 guesses whatever the pool. That is deliberately conservative: the estimator would rather underrate a random password than overrate a patterned one. The score is still 4, the top band.

From guesses to crack time

A guess count becomes a time once you know how fast the attacker can guess. That speed depends almost entirely on where they are guessing.

Online, rate limited (100 guesses per hour). The attacker types guesses into the real login page, and the site slows them down or locks the account. Even a score-2 password survives a long time here.

Online, not rate limited (10 per second). A poorly protected API that lets a script hammer it. Still slow by computing standards.

Offline, slow hash (10,000 per second). The site was breached and the attacker has the password database, but the passwords were stored with a deliberately slow function such as bcrypt, scrypt, Argon2id or PBKDF2 with a high iteration count. Each guess costs real computation.

Offline, fast hash (10 billion per second). The database stored unsalted MD5 or SHA-1, which GPUs compute at enormous rates. This is the worst case, and it still happens.

These four figures come from zxcvbn's original design and are deliberately round. Real numbers vary: a large GPU rig can exceed 10 billion fast hashes per second, and bcrypt at cost 12 on the same hardware allows far fewer than 10,000. The checker lets you enter your own rate so you can test a specific threat, for example 10^12 for a well-funded attacker against a fast hash.

The lesson from the table is that the same password can be fine or hopeless depending on how the website stores it, which you do not control. A strong password is insurance against the site getting it wrong.

What the 0 to 4 score means

zxcvbn maps guesses to a score with fixed thresholds:

Score 3 is a sensible minimum for anything important; score 4 is what you want for a password manager's master password or disk encryption, where an attacker who steals the encrypted file can guess offline for as long as they like.

What NIST SP 800-63B-4 asks for

The US National Institute of Standards and Technology rewrote its password guidance in SP 800-63B, and the 2025 revision (800-63B-4) tightened it further. Section 3.1.1.2 says that verifiers:

• shall require at least 15 characters when the password is the only authenticator, and at least 8 when it is one factor of a multi-factor login;
• should allow at least 64 characters, and accept spaces and Unicode;
• shall compare new passwords against a blocklist of commonly used, expected or compromised values, checking the whole password rather than substrings;
• shall not impose composition rules such as "one uppercase, one digit, one symbol";
• shall not require periodic changes, but shall force a change when there is evidence of compromise.

Composition rules were dropped because they push people towards exactly the predictable decorations shown above, while doing little for real strength. Forced expiry was dropped because people respond with Password1, Password2, Password3.

The checker's NIST panel tests the length thresholds and whether the password (or a near variant) is on zxcvbn's common-password list. That list is far smaller than a full breach corpus, so a pass there is necessary but not sufficient. To check against hundreds of millions of breached passwords, use Have I Been Pwned's Pwned Passwords service, which uses a k-anonymity design: your browser sends only the first five hex characters of the password's SHA-1 hash.

Making a strong password that you can remember

The numbers point to two practical methods.

Use a password manager and a generator for almost everything. A 20-character random password from the Password Generator is about 130 bits and you never need to type it.

Use a passphrase for the few things you must remember: the password manager itself, your computer login, disk encryption. Pick four to six words at random, ideally with dice from a list such as the EFF long word list, which has 7,776 words, so each word adds log2(7776) ≈ 12.9 bits. Five words give about 64.6 bits of real entropy, because the words really were chosen at random. Spaces or other separators are fine; capitals and symbols are optional.

What does not work, according to every measurement:

• A single dictionary word with substitutions, however clever.
• Personal information: names, birthdays, pets, the site name. Enter these in the "words about you" box to see how much they cost you.
• Keyboard walks and sequences, including long ones like 1qaz2wsx3edc.
• Reusing a password on two sites, whatever its score. If one site leaks it, the attacker does not need to guess at all.

Limits of any strength meter

A meter can only judge the password in front of it. It cannot know whether you have used the same password elsewhere, whether it is in a breach, or whether an attacker knows your partner's name. zxcvbn's word lists are English-centric, so a common word in another language may be treated as random letters and overrated. And all crack times assume an attacker who has to guess; phishing and malware bypass guessing altogether, which is why a second factor such as a TOTP authenticator code matters as much as the password.

Use the score as a sanity check, use length as the main lever, and let a password manager carry the rest. If you are on the other side of the login form, store passwords with a slow, salted hash; the Bcrypt Hash Generator shows what that looks like.

Sources

• D. L. Wheeler, "zxcvbn: Low-Budget Password Strength Estimation", USENIX Security 2016.
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, section 3.1.1.2 (2025).
• OWASP Password Storage Cheat Sheet (Argon2id, scrypt, bcrypt and PBKDF2 parameters).
• zxcvbn-ts project documentation and source, version 3.

Open the Password Strength Checker