From brute force to a realistic guess count
The starting point is brute-force entropy: the length multiplied by log2 of the character pool the password draws on. Lower-case letters count 26, upper-case 26, digits 10 and anything else 33. That number assumes every character was chosen at random, which is rarely true of a password a person made up, so it is only the ceiling.
The checker then finds predictable segments and replaces their share of the entropy with a much smaller figure. A year is worth under 8 bits wherever it sits, since there are only 200 of them between 1900 and 2099. Characters outside any pattern keep their brute-force value, and the final estimate never exceeds the ceiling.
The patterns it detects
Matches appear under Predictable parts found, masked with dots unless you have switched the password to visible. Substitutions such as 0 for o, 3 for e, @ for a and $ for s are undone before the lists are searched, so P@ssw0rd is caught as the common password it is.
Passphrases get their own rule. Three or more words separated by spaces, hyphens, underscores or dots are valued at about 14 bits per word, the figure for a word picked at random from a 20,000-word list, whenever that is lower than the character-based estimate. Four such words come to roughly 59 bits, which is rated Strong.
- Common password: the whole string is a listed favourite
- Dictionary word: a common word or name of four letters or more
- Year: any four digits from 1900 to 2099
- Sequence or repetition: abcd, 4321, aaaa or abcabc
- Keyboard pattern: four or more keys along a row, such as qwer
- Digits at end: up to four digits after letters, plus an optional symbol
Reading the crack-time table
Each row divides half the estimated guesses, the average an attacker needs, by an assumed speed. The first two rows model a live login: 100 attempts an hour where lockouts apply, and 10 a second where they do not. The last two model a stolen password database: 10,000 guesses a second against a slow hash such as bcrypt, and 100 billion against a fast one.
You usually cannot know how a site stores passwords, so plan for the bottom row. The speeds are round assumptions, not measurements of particular hardware, and times are printed coarsely, from instantly to centuries. Use the table to compare two candidate passwords, not as a promise about either.
How the breach check keeps the password private
The check uses the Pwned Passwords range service run by Have I Been Pwned, which holds SHA-1 hashes of passwords seen in real breaches. Your browser computes the 40-character hash and sends its first five characters to DNSfinder, which forwards that prefix and asks for a padded response so the reply size reveals nothing. Back comes every hash ending that shares the prefix, with a count for each.
The page then looks for your ending in that list. A match shows Found in a number of breached password records: the exact password is in circulation and should be retired everywhere. No match shows Not found in any known breach, which rules out one risk and says nothing about strength. Editing the password clears the result.
Where the estimate can be too generous
The built-in lists are short: about a hundred common passwords and a similar number of everyday words and names. Attackers use dictionaries with millions of entries in many languages. An uncommon word, a surname or a pet's name passes here as random letters. Tr0ub4dor&3, built on an unlisted word, gets 72 bits and no predictable parts. Passwords under 12 characters are capped at Strong for that reason.
The checker also knows nothing about you. It cannot tell that the digits are your birthday or that the same password guards three other accounts. For anything that matters, take a password from the random password generator and keep it in a manager. Site owners should store passwords as slow salted hashes, which the password encryption tool produces.