How to choose and test a strong password

Entropy: the only honest measure

A password’s strength is the number of tries an attacker needs, on average, to guess it. Counting that number directly is unwieldy, so we take its base-2 logarithm, entropy, in bits. Each bit doubles the search space: 40 bits is about a trillion combinations; 80 bits is a trillion trillions. The point almost every tutorial gets wrong is this: entropy is not a property of the string. It is a property of the process that generated it. The same sequence of characters can be worth 3 bits or 60, depending on how you arrived at it.

The formula falls out of counting combinations: if you draw L independent symbols, each from a set of R options, there are R^L possible passwords, and log2(R^L) = L × log2(R). Notice the word “draw”. The count only holds under uniform randomness, a die, a cryptographic generator, never your head. When a person chooses, they pile probability onto a tiny set of outcomes (names, dates, the capital-first-number-last pattern), and the attacker starts there. Real entropy becomes the log of your password’s position in a good attacker’s guess list, not the log of the theoretical set size.

The chart tells the whole story. Eight random lowercase characters give just 37.6 bits, inside the “weak” band of any meter. Adding character types helps (alphanumeric climbs to 47.6), but the big jump comes from length: twelve characters with symbols reach 78.8 bits, and, the counterintuitive part, six random words from a Diceware list reach almost the same (77.5 bits) while being far easier to remember. Now the example that opens the article, with the numbers spelled out.

// "P@ssw0rd!" tratada como aleatória / treated as random
L = 9 caracteres, R = 95 (minúscula + maiúscula + dígito + símbolo)
H = 9 × log2(95) = 9 × 6,5699 ≈ 59,1 bits   ← o que a conta ingênua diz

// "P@ssw0rd!" como o que realmente é / as what it actually is
base = "password"  (entre as ~20 senhas mais vazadas do mundo)
regra = capitaliza + a→@ + o→0 + acrescenta "!"  (a mangling mais comum)
um ataque de dicionário+regras chega nela em ~16 tentativas
H_real ≈ log2(16) ≈ 4 bits   ← o que um atacante realmente gasta

Why length beats complexity

In the formula, length and alphabet enter differently. Growing the alphabet R raises the base once: going from lowercase (26) to all printable symbols (95) multiplies the space by a fixed factor, and that is it. Growing the length L raises the exponent, and you can do that with no ceiling. Each extra random character multiplies the whole space by R again. That is why complexity runs out fast and length does not.

Read the table diagonally. Every symbol on the keyboard adds at most about 22 bits to a 12-character password (from 56.4 lowercase to 78.8), and charges that price in memorization and typos. Four extra lowercase characters (from 12 to 16) add 18.8 bits, and nothing stops you adding another four, and four more. A 16-character lowercase password (75.2 bits) already beats any 8-character password, however many symbols it holds (52.6 bits). Complexity is a one-time bonus; length is a treadmill that never ends.

Diceware passphrase: easy to remember, hard to crack

If random length wins, the challenge is generating length a human can remember. The answer is Diceware, published by Arnold Reinhold in 1995: you roll five six-sided dice, read the result in a numbered list and get a word; repeat a few times and join the words. Because each word comes from a list of exactly 6^5 = 7,776 entries, each one adds log2(7,776) ≈ 12.9 bits, and, crucially, those bits are real because the draw is uniform (dice have no preferences). The EFF long list, from 2016, holds those 7,776 words chosen to be common, easy to type and with no word a prefix of another.

7,776 words

The list size, equal to 6^5, the number of outcomes of five six-sided dice, so one roll yields one word without bias.

≈ 12.9 bits per word

log2(7,776). That is how much entropy each drawn word adds, provided it is genuinely drawn, with dice or a cryptographic generator.

Prefix property

No word in the EFF list is the start of another, so the passphrase reads unambiguously even written without spaces.

It is worth comparing head to head a six-word passphrase against a random twelve-character password, the other popular extreme:

// Passphrase Diceware de 6 palavras / 6-word Diceware passphrase
H = 6 × log2(7776) = 6 × 12,925 ≈ 77,5 bits
exemplo: "correto-cavalo-bateria-grampo-limao-trilho"

// Senha aleatória de 12 caracteres com símbolos / random 12-char with symbols
H = 12 × log2(95) = 12 × 6,5699 ≈ 78,8 bits
exemplo: "9x!Kd2#vQ7@m"

// Praticamente empatadas em bits, mas só uma delas você decora.

What NIST changed, and why

The “complexity rule”, at least one uppercase, one digit and one symbol, change the password every 90 days, did not fall from the sky. It has an author and a date, and the very agency that popularized it has since abandoned it. The document that defines best practice today is NIST SP 800-63B, whose current revision is SP 800-63B-4, finalized in July 2025. It dismantles, item by item, the playbook we taught for twenty years.

1. 2003The complexity rule is born

   A NIST appendix (SP 800-63, a memo attributed to Bill Burr) recommends mixing character types and changing passwords often. It becomes corporate law worldwide.

2. 2017Revision 3 walks it back

   SP 800-63B (rev. 3) drops composition rules and periodic expiration, based on research showing they produced worse passwords. Burr publicly admits he regretted the original advice.

3. 2025SP 800-63B-4 consolidates

   The fourth revision, final, raises the recommended minimum to 15 characters when the password is the only factor, requires comparison against breached-password lists and reinforces that composition rules and periodic expiration must not be imposed.

The logic behind every row is the same one that opens this guide. Composition rules and forced changes do not add randomness, they restrict human behavior to patterns, and patterns are what an attacker maps first. Requiring a symbol makes almost everyone put it at the end; requiring a quarterly change makes almost everyone increment a number. NIST swapped “force the user to complicate” for “let the user lengthen and block what has already leaked”. That is the difference between fighting the attacker’s math and feeding it.

How to test (and what the meter computes)

An honest meter does not count characters: it estimates entropy and then subtracts the bits the password gives away for free. This site’s password strength auditor does exactly that, and it helps to know what it computes underneath, it is not Dropbox’s zxcvbn, but a lighter cousin in the same spirit. First it estimates naive entropy from the detected character set (length × log2 of the set size). Then it applies penalties: it subtracts bits when it sees sequences, repeats, keyboard patterns, dates and leetspeak of common words, and it zeroes the score when the password appears in an embedded list of the most-leaked ones. zxcvbn, presented by Daniel Wheeler at USENIX Security 2016, takes the idea further, matching the password against dictionaries and estimating the guess count of several real attacks; the lesson common to both is the same: strength is the log of the guesses a good attacker spends, not the log of the theoretical set size.

• Prioritize length: 15+ random characters or 5–6 drawn Diceware words.
• Do not rely on leetspeak or the capital-first-number-last pattern.
• One unique password per site, kept in a manager, never reuse.
• Check whether it has leaked (via k-anonymity) and avoid any blocklisted password.
• Turn on a second factor: a passkey preferably, then an app TOTP; avoid SMS.
• Only type real passwords into local tools that send nothing to a server.

After choosing: store and reinforce

Choosing a good password is half the job; the other half is how it lives on both sides. On yours, use a manager to keep one long, unique password per service, generated by the password generator, so one site’s leak does not poison the others. On the storing side, the password must never sit in plain text: it becomes a salted hash via a deliberately slow function (bcrypt, scrypt, Argon2), as the bcrypt generator shows. The hashing, encryption and encoding guide explains why that slowness is a defense, not a defect.

This is where crack time earns its meaning, and where it is easy to invent a number. This site’s auditor estimates the time by dividing the needed guesses across attacker profiles: a throttled form (about 100 tries per hour), an unthrottled service (tens per second), a slow offline hash (~10 thousand/s, the case of a well-tuned bcrypt), a fast hash on a GPU (~10 billion/s) and a GPU cluster (~1 trillion/s). Those are the meter’s 2026 reference profiles, not a benchmark of any specific card, real speed depends entirely on the server’s password-hash algorithm. A high-cost bcrypt is orders of magnitude slower to attack than raw SHA-256, which is why the hash choice matters as much as the password choice. For scale: a 77.5-bit passphrase needs, on average, about 2^76.5 ≈ 10^23 guesses; even at cluster pace (10^12/s), that runs into thousands of years. The 37.6 bits of eight lowercase characters, on the same cluster, fall in a fraction of a second.

Finally, turn on two-step verification. Even if a password leaks, a second factor blocks access, but not every second factor is equal. Prefer a passkey, which resists phishing by binding the signature to the site’s origin; where it is not available, use an app TOTP code, like the TOTP generator’s, rather than SMS, which can be diverted by a SIM swap. It is the layer that turns a leak into a scare, not a breach, the same defense-in-depth logic that shields a whole domain in the SPF, DKIM and DMARC guide.