# Password strength: what entropy actually measures > Password strength is measured in bits of entropy - length x log2(character pool size). Length matters far more than complexity: a 20-character random lowercase password is stronger than a 10-character one full of symbols. Aim for 80 bits or more, and stop rotating passwords on a schedule. Source: https://rankcert.com/blog/password-strength-explained Published: 2026-09-02 ยท Updated: 2026-09-02 --- A password's strength is not a feeling. It is a number: how many guesses an attacker needs before they are more likely than not to have found it. ## Entropy in one formula Entropy in bits is `length x log2(pool size)`. A 12-character password from lowercase letters only draws from a pool of 26, so `12 x log2(26)` = about 56 bits. The same length using upper, lower, digits and symbols draws from about 90, giving 78 bits. Now compare that to simply making it longer. Twenty lowercase characters is 94 bits - stronger than the twelve-character password with every character class enabled. That is the whole argument for length over complexity. Each extra character multiplies the search space by the pool size; adding a symbol class only widens the base. Free tool: [Password Generator](https://rankcert.com/tools/password-generator) - Generate strong random passwords in your browser using the Web Crypto API, with an entropy figure so you can see how strong they actually are. ## What the numbers mean - **Under 50 bits** - falls to a determined offline attack against a leaked hash. - **60 bits** - adequate for a low-value account behind rate limiting. - **80 bits** - beyond realistic offline cracking with current hardware. - **100+ bits** - not going to be guessed, ever, by anyone. These assume the password is genuinely random. Entropy calculations describe the *generation process*, not the string. `Tr0ub4dor&3` looks like 11 characters of high complexity and is worth about 28 bits, because it was produced by a predictable set of substitutions applied to a dictionary word. ## The advice that got reversed NIST's 2017 revision to SP 800-63B dropped two rules that had been near-universal: **Scheduled rotation.** Forcing a change every 90 days produced `Summer2024!` followed by `Autumn2024!`. Predictable increments are worse than a strong password left alone. Change a password when there is a reason - a breach, a shared device, a departing employee. **Composition rules.** Requiring one of each character class narrows the search space rather than widening it, because everyone satisfies it the same way: capital at the start, digit and exclamation mark at the end. What replaced them: a long minimum, a check against known-breached password lists, and no arbitrary maximum length. A service that caps your password at 16 characters is telling you something about how it stores them. ## Passphrases Four or five random words from a large list - the Diceware approach - gives roughly 12.9 bits per word. Four words is about 52 bits, six is 77. Passphrases are for what you must memorise: a device login, a password manager master key. Everything else should be long random strings that a manager holds and you never see. The point of a manager is that only one credential needs to be memorable. The word list has to be random. Choosing four words yourself produces something closer to a phrase than a passphrase, and phrase-shaped guesses are exactly what modern cracking rules generate first. ## Where randomness comes from `Math.random()` is not a security primitive. It is seeded predictably and its output can be reconstructed from a handful of samples. Use `crypto.getRandomValues` in the browser, `crypto.randomBytes` in Node, `secrets` in Python. Anything generating credentials, tokens or reset links must use a cryptographically secure source, and the difference is invisible until it is exploited. Also watch the modulo bias: taking a random 32-bit integer modulo a 90-character pool skews slightly toward the early characters. It is a small effect and easy to avoid by rejecting values above the largest clean multiple. ## What a password cannot do None of this helps against a phishing page that receives the password directly, or a service that stores it badly and gets breached. Two-factor authentication covers the first case, and a passkey or hardware key covers it completely, because there is no shared secret to phish. Unique passwords per site cover the second, which is the actual reason to use a manager - not strength, but the fact that a breach at one service stays at that service. Generate one with the [password generator](/tools/password-generator), which uses the Web Crypto API and shows the entropy figure for whatever settings you pick.