Hashcat Bcrypt Benchmark 2026: RTX 5090, RTX 4090, RX 7900 XTX Speed Table (Mode 3200)

If you searched for "hashcat benchmark mode 3200 bcrypt RTX 4090 180 kH/s" and landed on a generic GPU table that didn't answer the question, this page is the direct answer. Below is a focused benchmark table for hashcat mode 3200 (bcrypt) across current and recent GPUs, with exact figures for the RTX 4090, RTX 5090, RX 7900 XTX, and others.

Legal notice: Password cracking should only be performed on hashes from systems you own or have explicit written authorization to test. Unauthorized cracking is illegal.

Why Bcrypt Is Uniquely Hard for GPUs

Most hash functions — MD5, SHA-1, NTLM — were designed for speed. A modern GPU can compute billions of MD5 hashes per second because the algorithm fits neatly into parallel GPU execution units.

Bcrypt was designed to be the opposite. The Blowfish cipher at its core requires a large, continuously mutating subkey table. Each candidate password requires hundreds of sequential memory reads and writes that depend on the previous step's output. This serializes work across GPU threads and kills the parallelism that makes GPUs fast for other hash types.

The result is that bcrypt runs at roughly the same speed on a CPU as on a GPU — normalized per compute unit. Throwing 16,000 GPU cores at bcrypt does not produce a 16,000x speedup. It produces perhaps a 50-100x speedup, and that's before considering that each GPU core is much slower per-clock than a CPU core.

This is not a hashcat limitation. It is by design. Bcrypt's resistance to GPU acceleration is the primary reason it remains the recommended hash for storing passwords in 2026.

What Is Bcrypt Mode 3200 in Hashcat?

In hashcat, -m 3200 targets bcrypt hashes, specifically the $2*$ family produced by the Blowfish-based crypt algorithm. This is the hash type found in:

• Linux /etc/shadow when bcrypt is configured
• WordPress password hashes (using phpass with bcrypt)
• Many PHP, Ruby on Rails, and Node.js web applications
• Any system using bcrypt from OpenBSD's original implementation

Cost factor explained

The $2b$10$ prefix in a bcrypt hash encodes two things: the variant (2b) and the cost factor (10). The cost factor is an exponent: cost 5 means 2^5 = 32 rounds of key setup; cost 10 means 2^10 = 1024 rounds. Each increment doubles the computation time.

Hashcat benchmarks at cost factor 5 by default for mode 3200. Most benchmarks you find online — including the RTX 4090 figure of 180 kH/s — are at cost factor 5.

Production systems use cost 10 to 12. This is critical when evaluating whether cracking is feasible. An RTX 4090 at 180 kH/s (cost 5) drops to approximately 5-6 kH/s at cost 10. Brute-forcing an 8-character mixed-case password space at 5 kH/s would take millions of years.

How to Run the Bcrypt Benchmark Yourself

Run the built-in hashcat benchmark for mode 3200:

# Benchmark bcrypt (mode 3200) on all available GPUs
hashcat -b -m 3200

# Benchmark on a specific device (replace 1 with your device index)
hashcat -b -m 3200 -d 1

# List available devices first
hashcat -I

Expected output format:

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix)

Speed.#1.........:   180.1 kH/s (89.78ms) @ Accel:4 Loops:32 Thr:16 Vec:1

The fields to read:

• Speed.#1 — device 1 speed in hashes per second
• Accel — number of work items per compute unit batch
• Loops — number of bcrypt rounds processed per kernel launch (limited to 32 at cost 5)
• Thr — threads per work item

The kH/s figure is what you compare against the table below. If you see H/s instead of kH/s, your speed is below 1,000 hashes per second — which is expected behavior if you're testing at cost 10 or 12.

Hashcat Bcrypt Speed Table (Mode 3200, Cost Factor 5)

All figures are at cost factor 5 ($2b$05$), which is the default hashcat benchmark baseline. Speeds are from community benchmarks, manufacturer specifications, and verified hashcat -b output. The RTX 4090 figure of 180 kH/s is the consistently reported result across multiple independent sources.

Scaling to other cost factors: Speed scales inversely with cost factor iterations. Cost 10 is 32x slower than cost 5 (2^(10-5) = 32), so divide the table figure by 32 to get cost 10 speed.

At cost 12, even a 250 kH/s GPU is doing under 2,000 hash attempts per second. An 8-character lowercase password space has 26^8 = 208 billion combinations. At 2 kH/s, exhaustive brute force of that space alone would take over 3,000 years.

Bcrypt vs WPA2 Speeds on the Same GPU

This comparison is useful for understanding why bcrypt is categorically different from other hash cracking targets. WPA2 in hashcat (mode 22000, PMKID/EAPOL) is already considered slow — but bcrypt is thousands of times slower still.

The ratio exists because WPA2-PMKID uses PBKDF2-SHA1 with 4,096 iterations — already a slow hash — but SHA-1 itself runs at hundreds of GH/s on modern GPUs, so even with 4,096 iterations, GPU parallelism provides a massive advantage. Bcrypt's memory-hard sequential design eliminates that advantage almost entirely.

What This Means for Password Auditing

Cost factor 5 (legacy or test systems)

At 180 kH/s, an RTX 4090 can test 180,000 candidate passwords per second. Against a targeted wordlist of a few million entries, this is trivially fast — a complete rockyou.txt run finishes in under a minute. Short brute-force attacks on 6-7 character passwords are feasible over hours or days.

Cost factor 10 (standard production)

At ~5.6 kH/s, an RTX 4090 tests 5,600 passwords per second. A full rockyou.txt run (14 million entries) takes about 40 minutes. Brute force of anything beyond 6 characters is not practical. Dictionary attacks with well-targeted wordlists remain the viable approach.

Cost factor 12 (hardened systems, e.g., Django default)

At ~1.4 kH/s, a rockyou.txt run takes over 2.5 hours per hash. For a database dump of thousands of hashes, this compounds: 10,000 hashes at 1.4 kH/s means testing one wordlist entry against all 10,000 hashes in parallel (hashcat handles this automatically), so throughput stays at 1.4 kH/s total regardless of hash count — but each additional hash in the file gets evaluated simultaneously, making large-scale cracking of a full dump more viable than single-hash cracking might suggest.

Recommendation: Any new system storing user passwords should use bcrypt at cost 10 or higher. Cost 12 is appropriate for systems where login latency of 200-400ms per authentication attempt is acceptable. Do not use cost 5 in production — it exists only for benchmarking and legacy compatibility.

Cloud GPU Alternatives

Cloud instances with A100 or H100 GPUs are not dramatically faster for bcrypt despite their theoretical compute advantage. The H100 SXM5 produces roughly 300-350 kH/s for bcrypt at cost 5 — a meaningful improvement over the RTX 4090's 180 kH/s, but not the order-of-magnitude gap seen with CUDA-friendly hash types like MD5 or NTLM.

This is bcrypt doing its job. The memory-hard, sequential design of the Blowfish key schedule limits the speedup from larger GPU memory bandwidth and more SM units.

For large-scale auditing of bcrypt hashes at cost 5, a multi-GPU system with 4x RTX 4090 (720 kH/s combined) or equivalent cloud spot instance is a practical configuration. For cost 10 or higher, no GPU configuration makes exhaustive cracking feasible against long or complex passwords — targeted wordlist and rule attacks are the only viable strategy.

Related Articles

• Hashcat GPU Benchmarking Table: Nvidia and AMD — Full benchmark table across hash modes for both GPU families
• Best GPU for Hashcat 2026 — GPU selection guide covering cost-per-hash and VRAM requirements
• Hashcat Wordlist Attack Tutorial — Step-by-step dictionary attack guide using rockyou.txt