Make a strong, random password to use for a website, account, or login.
The "bits" number measures how many guesses it would take to crack the password. Each bit is like a coin flip's worth of uncertainty, and every extra bit doubles the number of possible passwords — so the guesses needed grow explosively, not steadily. Going from 40 to 80 bits isn't twice as strong; it's roughly a trillion times more combinations to search through.
Here's roughly how long that takes a computer trying billions of guesses per second:
| Bits | Time to crack |
|---|---|
| 20 | Instantly |
| 40 | About a minute |
| 50 | About a day |
| 60 | About 2 years |
| 80 | Millions of years |
| 100 | Trillions of years |
| 128+ | Longer than the universe has existed |
This is a worst-case estimate — real websites usually slow attackers down far more than this.
The math itself is just arithmetic anyone can check: each extra bit of entropy doubles the number of guesses needed, so total guesses = 2^bits. Dividing that by an attacker's guess rate gives the time shown above. The part worth sourcing is the guess rate (10 billion/sec) — that's a round, conservative figure based on real hardware. Hashcat's own documentation, the standard open-source tool security researchers use to benchmark password-cracking hardware, shows an example benchmark run hitting roughly 16 billion MD5 hashes per second — and that was on GPU hardware from several years ago, so current high-end hardware benchmarks even higher for fast, unsalted hashes. It's a worst-case number: well-designed sites use slower hashing (bcrypt, Argon2, scrypt) that cuts attacker speed by orders of magnitude.
For the offline-attack threat model this table assumes — and the general idea of measuring secrets in bits of entropy — see the U.S. government's NIST SP 800-63B-4 (once open, search the PDF for "Password Verifiers" to jump to Section 3.1.1.2). It requires stored passwords to be salted and hashed specifically to make offline guessing expensive, and uses explicit bit-entropy thresholds elsewhere in the document (e.g. cryptographic keys need at least 112 bits). Worth noting: NIST's current guidance has moved away from scoring user-chosen passwords by entropy — it now favors simple length minimums and blocklists over composition rules (Sec. 3.1.1.1, findable the same way). The entropy math here is still valid, just applied a bit differently than NIST currently recommends for how sites should design their password policies.
How much is enough?
For most everyday accounts, "Good" or better is plenty. Save "Excellent" for the accounts that matter most:
A note on tool use
This tool protects your password from ever leaving your device — but device-level security (keeping your browser and system updated, avoiding untrusted extensions) still matters here, the same as with any password tool.