Test Which Attack Your Password Must Survive

Test Which Attack Your Password Actually Needs to Survive

Check your password's entropy above, then decide which threat model actually applies to it: a hundred guesses an hour versus roughly three hundred billion guesses a second is the realistic gap between an online and an offline brute-force attack against the exact same password. An online attack submits guesses directly to a live login service, one at a time, constrained by whatever rate limiting and lockout policy that service enforces. An offline attack works against a password hash an attacker has already obtained, typically from a data breach, with no network round-trip and no rate limit standing in the way beyond raw compute power.¹² The same password can survive one attack type indefinitely while falling to the other in seconds, which is why deciding which threat model applies to your situation matters more than staring at the entropy score in isolation.

What defines an online attack

An online attack submits login attempts through the same interface a real user would use, a website's login form or an API endpoint, and every attempt costs the attacker network round-trip time plus whatever delay the service imposes. NIST identifies throttling as the primary defense against this attack type, and a typical throttled policy might allow only around 100 guesses per hour before triggering a lockout or a CAPTCHA challenge.¹

Under that constraint, even a password with modest entropy can survive indefinitely, since the attacker's guess budget is the bottleneck, not the size of the keyspace. A service with no throttling at all, however, collapses this advantage entirely, turning what should be an online attack into something closer to an unthrottled guessing race.

Why rate limits shrink the attacker's timeline to years rather than minutes

Rate limiting turns online attack defense from a password strength problem into a policy problem. A service that allows only around a hundred guesses per hour before locking out or challenging the requester makes even a weak password effectively impossible to enumerate, because the attacker's timeline stretches from seconds to years or longer. That protective effect disappears when the backend does not enforce throttling or when the attacker rotates through enough source IP addresses to avoid per-account lockouts, which is why no single entropy number can tell the full story for an online-facing password.

What defines an offline attack

An offline attack starts after an attacker has already obtained a password hash, most often through a database breach, and runs entirely on the attacker's own hardware with no rate limit at all. A single consumer GPU like an RTX 4090 can test roughly 300 billion NTLM or MD5 hashes per second, a rate that turns a modest keyspace into a target crackable within hours rather than years.²

Why the hashing algorithm decides the outcome here

A slow, deliberately expensive hash function like bcrypt changes this picture dramatically. The same RTX 4090 running bcrypt at cost factor 12 manages only around 1,560 hashes per second, roughly 190 million times slower than its NTLM rate.³ Offline attack resistance depends jointly on your password's entropy and the hashing algorithm the breached service chose, a variable entirely outside your control as a user.

From the user's perspective this split matters most when deciding how much entropy a password needs: a password that only needs to resist online guessing does not have to be especially long, because throttling caps the attacker's budget, but the same password protecting something worth a breach will eventually face an offline environment where only raw entropy and the server's hash choice determine survival.

Why the same password can be safe in one scenario and trivial in the other

A modest, moderately common password behind strict online throttling can go untested for years, simply because the attacker never gets enough guesses to reach it. That same password, if the service storing it suffers a breach and used a fast, unsalted hash, can fall in well under a second once the hash reaches an attacker's GPU. The password did not change; the threat model did.

Conversely, a very high-entropy password offers little extra protection against online throttling, since the attacker was already limited to a handful of guesses regardless of keyspace size, but it offers enormous protection if the storage backend is ever breached. Because you cannot control which scenario you will eventually face, treating every password as if it might someday be attacked offline, favoring length and a unique value per site, is the only strategy that holds up under both threat models at once, since the offline crack-time math behind a stolen hash rewards genuine randomness in a way that throttling policy alone never has to.⁴

The mirror-image choice facing service operators

Service operators face the mirror version of this same choice. Investing in a slow hashing algorithm costs almost nothing at login time, since a legitimate user only ever hashes their password once per attempt, but it multiplies the cost of every single guess an attacker makes after a breach, which is exactly where the real economic tradeoff between the two threat models plays out and why the choice matters long after a breach has already happened.⁵

When to use this

Use the entropy checker above alongside this framework to decide how much entropy a specific password actually needs. A password behind strict lockout policies and no history of breaches leans more on throttling than raw entropy; a password protecting something valuable enough to be a breach target should be built to survive an offline attack regardless of the service's own defenses.

Examples