How long a password survives brute force on 8× RTX 4090

Password strength is usually imagined as “complexity”: add a digit, a capital, an exclamation mark. The math of brute force says otherwise. What decides is not the character set but the length — and the gap there is not a factor, it is orders of magnitude.

Below is an estimate of the time to fully brute-force a random password on a real GPU rig of eight NVIDIA RTX 4090 cards. Every figure has been verified by an independent calculation.

What we are actually computing

The password space is the number of all possible passwords of a given length:

K = N^L

where N is the alphabet size and L the length. The maximum brute-force time is the whole space divided by the speed:

T_max = N^L / R

The average expected time is half of that, because the correct password is equally likely to sit anywhere. This is an upper bound for a random password: the attacker knows nothing about its structure and must try everything.

One caveat up front: this is offline brute force. The attacker already has a copy of the hash database and tests candidates on their own hardware. Server-side defences — lockout after failed attempts, CAPTCHA, rate limits — do not apply here. That is exactly why a leaked hash database is so dangerous.

The platform

The baseline speed is taken for the NTLM algorithm on eight RTX 4090s:

R = 2.24 × 10¹² hashes/s  (280 GH/s per card × 8)

NTLM is chosen deliberately: it is one of the fastest algorithms, i.e. the worst case for the defender — the maximum speed an attacker could have for a typical fast hash. MD5, SHA-1 and SHA-256 are slower but of the same order; purpose-built password algorithms are many orders of magnitude slower (more on that at the end).

The master table

Maximum full-brute-force time for a random password, four alphabets. Rounded to three significant figures.

Length	Digits only (N=10)	Letters only (N=52)	Digits + letters (N=62)	All ASCII (N=95)
6	0.446 µs	8.83 ms	25.4 ms	0.328 s
8	44.6 µs	23.9 s	1.62 min	49.4 min
10	4.46 ms	17.9 h	4.34 days	309 days
12	0.446 s	5.53 years	45.6 years	7.64 thousand yr
14	44.6 s	14.95 thousand yr	175 thousand yr	69.0 million yr
16	1.24 h	40.4 million yr	674 million yr	623 billion yr
18	5.17 days	109 billion yr	2.59 trillion yr	5.62 × 10¹⁵ yr

Read the table twice — down the columns and across the rows. They tell two different stories.

Length versus character set

Across a row you see the effect of the alphabet. Take 12 characters: a digit-only password falls in half a second, while the same length in full ASCII holds for thousands of years. The difference is enormous — but it is fixed.

Down a column you see the effect of length, and this is where the main finding hides. Each additional character multiplies the whole space by the alphabet size:

• digits — ×10 per character;
• letters — ×52;
• digits and letters — ×62;
• full ASCII — ×95.

Since the table steps by two characters, the time between adjacent rows grows by N²: ×100, ×2704, ×3844, ×9025. This is not adding seconds — it is multiplying all of the previous time by a constant factor.

Hence a practical conclusion that runs against intuition:

A long password from a simpler alphabet is usually stronger than a short password from the largest possible character set.

Compare: an eight-character password from full ASCII is broken in 49 minutes, while a fourteen-character password of letters only takes almost 15 thousand years. Special characters do not rescue a short length.

Why this holds only for random passwords

The whole table is valid only when the password is a random string. The password

Password2026!

has 13 characters and formally belongs to the 95¹³ space. But its structure is predictable: a dictionary word, a capital first letter, the current year, a typical symbol at the end. An attacker will test such a construction long before touching any meaningful fraction of the space — with dictionaries, breach data, mutation rules, and if needed generative models like PassGAN.

The table’s numbers describe strings like T7vN2cR8pK5m, not Dubai2026. Mathematical length is not entropy.

Fast hashes versus slow ones

Everything above is for NTLM, a fast hash. But the storage algorithm itself changes R by many orders of magnitude without touching N^L:

Property	NTLM	bcrypt	Argon2id
Purpose	fast hashing	password storage	password storage
Tunable CPU cost	no	yes (cost factor)	yes
Tunable memory	no	no	yes
Resistance to GPU brute force	low	much higher	high

bcrypt is deliberately expensive: raising the cost factor by one roughly doubles the work. Argon2 goes further — it makes each check memory-hard too, which directly attacks the GPU’s main advantage: massive parallelism. If one check needs 64 MiB, the number of simultaneous jobs is capped by the video memory divided by that size.

The time formula stays the same; only R changes:

T = N^L / R

So the defence is two-layered, and both layers are mandatory. The user provides length and randomness. The system provides a slow algorithm (Argon2id by default, RFC 9106), a unique salt per password, and adequate cost parameters. A weak password under a strong algorithm still falls to a dictionary — a strong algorithm adds no entropy, it only makes each attempt more expensive.

Takeaways

• Against offline brute force, length is decisive. Every two characters is a new order of difficulty; a wider alphabet is a one-time gain, not a compounding one.
• 8 characters is not saved even by full ASCII — 49 minutes. The practical threshold for a random password starts at 12 characters and holds firmly from 14.
• The numbers hold only for random passwords. Predictable constructions fall far earlier than any table.
• Adding hardware shortens the time linearly; each added character grows the space exponentially. That asymmetry is on the defender’s side.
• Store passwords with a purpose-built algorithm (Argon2id, bcrypt) and a salt, not a fast hash.

Maximum resistance is not one property but a sum: a long random password + a unique salt + slow hashing + correct parameters.