"Use a strong password" is useless advice without a definition of strong. The definition that actually holds up is entropy — how many bits of randomness the password has — and once you see the math, most "complex-looking" passwords turn out weak.

The formula

Entropy in bits is: bits = length × log2(poolSize)

poolSize is how many characters each position could have been:

  • lowercase only → 26 → ~4.7 bits/char
  • lower + upper → 52 → ~5.7 bits/char
  • lower + upper + digits → 62 → ~5.95 bits/char
  • + symbols → ~95 → ~6.55 bits/char

So a 16-character password using all four classes is about 16 × 6.55 ≈ 105 bits in theory. A rough rule of thumb: < 50 bits is weak, 70–100 is solid, 100+ is strong for anything that could be attacked offline.

The punchline developers underestimate: length beats symbol-soup. Tr0ub4dour&3 (clever substitutions, 12 chars) has less entropy than a longer passphrase, because entropy scales linearly with length but only logarithmically with pool size. Add characters, not cleverness.

Why "human-chosen" ruins the math

The formula assumes each character is independently random. A human picking P@ssw0rd2024! doesn't get 13×6.55 bits — attackers' wordlists and mangling rules know that pattern, so the effective entropy collapses. The entropy number is only honest if the generator is actually random.

Generate one and see the number

Toolonium's password generator does exactly this and shows you the entropy as you tune it:

  • Length 8–64 (slider), default 16.
  • Toggle uppercase, lowercase, digits, symbols.
  • "No ambiguous characters" option to drop l/1/I/O/0 — useful when the password will be read aloud or typed from a screen.
  • It reports estimated entropy in bits and a strength label, so you're choosing with a number, not a vibe.

It runs entirely in the browser — the generated password is never sent anywhere, which is the only acceptable design for a tool whose whole job is producing a secret. (As always: for app-level generation use your platform's CSPRNG, e.g. crypto.getRandomValues; this is for the quick human-facing case — a new DB user, a seed, a one-off account.)

Takeaway

Stop eyeballing passwords. Pick a target of ~100 bits, get there with length first, and use a generator that's random and local so the entropy estimate is real. Try it here.

What entropy floor does your team enforce for service accounts? Curious where people draw the line.