What "1 Trillion Guesses Per Second" Actually Means for Your Password

Half the password articles on the internet quote a number like "100 billion guesses per second" or "an attacker can try a trillion passwords per second." The numbers vary by orders of magnitude depending on who is writing. Both numbers are correct for some scenario. What changes is the hash, the hardware, and whether the attack is online or offline.

Online vs Offline

First and most important: are we talking about an attacker logging into the real website, or an attacker who has a copy of the password hashes?

Online attack:the attacker types passwords into a login form. Rate-limited by the server. Even without rate limits, network round-trips cap throughput at maybe 100–1,000 attempts per second. With any reasonable lockout policy, it's effectively a few attempts per minute.

Offline attack: the attacker has stolen the password database (via SQL injection, server compromise, insider, etc.) and has the hashes locally. They can throw arbitrary hardware at it with no rate limit. This is where the trillions-per-second numbers come from.

The two scenarios are roughly nine orders of magnitude apart. Any password discussion that mixes them is talking past itself.

The Hash Function Decides Everything

For offline attacks, "guesses per second" is really "hashes per second". Each guess hashes the candidate and compares it to the stolen hash. Speed depends almost entirely on which hash function is in use:

• MD5, SHA-1, NTLM, plain SHA-256: designed to be fast. A single NVIDIA RTX 4090 does ~160 billion MD5/sec, 40 billion NTLM/sec. A small rented cluster easily hits the trillion mark.
• bcrypt at cost 10: ~30,000 hashes/sec on the same GPU. Six orders of magnitude slower than MD5.
• scrypt and Argon2id with reasonable parameters: hundreds to low-thousands of hashes/sec. Memory-hardness defeats the GPU advantage.

The same password is "breakable in seconds" against MD5 and "breakable in centuries" against Argon2id. The defender's choice of hash function matters more than the attacker's budget.

Where the Big Numbers Come From

Public benchmarks from Hashcat, run on consumer GPUs, are the source of most quoted figures. Here are some real ballpark numbers from a single RTX 4090 in 2024:

MD5         164 GH/s   (164,000,000,000/sec)
SHA-1        49 GH/s
NTLM        288 GH/s
SHA-256      22 GH/s
bcrypt c10   30 KH/s   (30,000/sec)
scrypt      2.5 KH/s
Argon2id   ~900   H/s

A serious attacker rents 100–1,000 such GPUs and runs them in parallel. So an "offline trillion-per-second" budget is realistic for fast hashes. For bcrypt, the same budget gets you maybe 30 million per second — still scary, but in a different league.

How to Translate to Password Length

The crack time for a randomly-chosen password is roughly:

time = (charset_size ^ length / 2) / guesses_per_second

Plugging in numbers, against an offline attacker doing 10^12 guesses/sec on a fast hash, you need approximately:

• Lowercase only (26 chars): 14 characters for ~14 days, 16 for centuries.
• Lowercase + digits (36): 13 characters for ~50 years.
• Mixed case + digits (62): 11 characters for ~50 years.
• Full ASCII (95): 10 characters for ~50 years.

Against bcrypt, knock about 7 orders of magnitude off the attacker's rate, which moves the bar down by 4–5 characters. Against Argon2id, you can use distinctly shorter passwords and still be safe.

The Honest Answer

You don't know which hash the site uses. You don't know whether they have a leak. You don't know how much hardware the attacker will throw at it next year.

So plan for the worst case: the database has been stolen, the hash is fast, and the attacker is well-funded. Under those assumptions, a 14-character random password or a 5-word EFF passphrase comfortably outlasts current crack-economic limits. Anything in a password manager should be longer than that simply because there is no reason not to be. The cost of typing it is zero, and you don't know what hash function the site picked in 2014.