We Gave Hashcat 6 Password Hashes. It Cracked 5 in Under a Second. The 6th Said No.

The Results

The critical number: NTLM vs bcrypt = 59,034× slower. Same hardware. Same dictionary. Same machine. The only difference is the hash function.

Note that Password1! was in the SHA-256 hash — it has uppercase, a number, and a special character. It meets every complexity requirement for most corporate password policies. It was cracked in under a second because it was in a commonly used wordlist. Complexity rules don't help when the password is common. Slow hashing functions do.

The Three Stories in the Data

1. SHA-512 Sounds Strong. It Isn't (for Passwords).

SHA-512 produces a 128-character hex string. It uses 512-bit internal state. Developers see it and feel safe — this is a serious cryptographic algorithm used in certificate chains and TLS handshakes. Which it is. For those purposes.

For passwords, the property that matters isn't output length or algorithm complexity. It's time per hash computation. SHA-512 is designed to be fast. It runs at 2.7 million hashes per second on a CPU. With a modern GPU it runs at tens of billions per second. The entire 14-million-password rockyou.txt dictionary takes under 6 seconds on our CPU, under 0.2 seconds on a gaming GPU.

"Stronger general-purpose cryptographic hash function" does not equal "more resistant to password cracking." These are different properties. The SHA algorithms were never designed for password storage.

2. NTLM Is the Worst Possible Option Still in Use

6.6 million hashes per second on a CPU-only ARM box. This is Windows's password format — the one that Active Directory uses by default for local account password hashes, and the one that attackers extract from LSASS memory dumps, SAM files, and NTDS.dit in domain controller compromises.

A modern GPU reaches 100+ billion NTLM hashes per second. The entire rockyou.txt dictionary takes 0.00014 seconds on a consumer gaming GPU. Every NTLM hash in a credential dump is effectively plaintext. If you're running any service or application that stores or transmits NTLM hashes, the content is exposed to anyone who extracts them.

This is why pass-the-hash attacks remain so effective in Windows environments: you don't even need to crack the hash. NTLM hashes can authenticate directly in many Windows authentication flows. The hash is the credential.

3. bcrypt Forces Attackers to Slow Down Permanently

112 hashes per second. Not 112 thousand. Not 112 million. One hundred and twelve.

Cracking the full 14-million-password rockyou.txt dictionary against a single bcrypt hash takes approximately 32 hours on this hardware. Each account requires another 32 hours. A database of 10,000 users would take 13 years of continuous CPU time.

On a GPU: bcrypt runs at 10,000–20,000 H/s. That's 10-20× faster than our CPU, versus the 50,000–100,000× speedup GPUs give for MD5 and NTLM. The ratio holds because bcrypt's design forces the computation to be sequential in ways that GPUs can't easily parallelise.

This isn't theoretical resistance — it's economic resistance. Mass cracking of bcrypt databases is not a viable attack at scale. Attackers move to easier targets. That's the practical effect.

Why Slow Hashing Is a Design Feature, Not a Bug

When developers complain that bcrypt is slow, that's the point. The slowness is calibrated:

• On login, verifying a bcrypt hash takes ~100ms — negligible to a human user, imperceptible in a web app context.
• For an attacker with a stolen hash file, 100ms per hash means 10 hashes per second, or ~600 attempts per minute against a dictionary.
• The work factor is configurable: $2b$12$ is 4× slower than $2b$10$. As hardware gets faster, increase the rounds to maintain equivalent resistance.

Why Argon2 Is Better Still

Argon2 won the Password Hashing Competition in 2015 and adds memory hardness to time hardness. Cracking Argon2 requires both compute time AND large amounts of RAM per attempt. Because GPUs have limited memory per core, this significantly reduces GPU-based cracking advantages. Recommended parameters: Argon2id, m=65536 (64MB), t=1 (1 pass), p=4 (4 parallel threads).

For new applications: use Argon2id. For existing applications on bcrypt with rounds≥10: the migration isn't urgent. For anything storing MD5, SHA-1, SHA-256, or SHA-512 passwords: migrate now.

The Salting Bonus (Not Shown in Demo)

Both bcrypt and Argon2 generate a unique random salt for each password hash. This means two users with the identical password produce completely different hashes. Pre-computed rainbow table attacks — the predecessor to dictionary attacks — become completely useless. Every hash must be cracked individually. This also means that discovering one user's password via cracking gives you nothing about other users with the same password.

MD5 and SHA-256 can be salted too — but salting doesn't help if the hash itself is computed in microseconds. The salt buys you nothing when the attacker can compute 3 million salted SHA-256 hashes per second on their laptop.

The Honest Gaps

CPU-Only Hardware

This demo ran on an ARM aarch64 CPU. A modern gaming GPU (RTX 4090) would crack:

• MD5 at ~100 billion H/s (100,000× faster than our demo)
• NTLM at ~150 billion H/s
• bcrypt at ~10,000–20,000 H/s (90–180× faster, but not the 100,000× speedup of MD5)

The bcrypt ratio still holds. The absolute resistance of bcrypt decreases with better hardware, but so does everyone's hardware — the defender upgrades the work factor, maintaining equivalent effective resistance. The fast hash algorithms have no equivalent defence.

Demo Wordlist Was 50K

We used the top 50,001 passwords from rockyou.txt. All 5 cracked passwords are in the top 1,000 most common passwords globally. We planted easy ones deliberately — this demo is about algorithm speed differences, not password policy. Real-world crack rates depend on your users' actual password choices.

We Didn't Demo GPU or Rainbow Tables

Pre-computed rainbow table attacks against unsalted MD5/SHA-1 are even faster than dictionary attacks — effectively instant for common passwords. bcrypt's per-hash unique salting defeats them completely. This is mentioned but not demonstrated here; it's an additional argument for proper key derivation functions.

The Immediate Action

If your application stores passwords as MD5, SHA-1, SHA-256, or SHA-512 hashes, you have a disclosure event waiting to happen. Any credential dump — database breach, backup theft, insider access — gives an attacker plaintext passwords for a significant portion of your user base within hours.

The fix is known, well-documented, and implementable in every major language:

• PHP: password_hash($password, PASSWORD_BCRYPT) / password_verify()
• Python: bcrypt library or Django's built-in PBKDF2PasswordHasher
• Node.js: bcrypt or argon2 packages
• Ruby: bcrypt-ruby gem
• Java: Spring Security's BCryptPasswordEncoder

Migration path for live applications: on next login, verify against the old hash, then re-hash with bcrypt and replace. Users who haven't logged in keep the old hash until they do. After a reasonable period, force password resets for remaining old-format accounts.

SecurityClaw's hashcat skill runs this analysis in one command against your credential store. The output maps which algorithms are in use across your user base and prioritises the migration.

For deeper reading on password security in the context of real-world attacks, the relevant chapters in The Web Application Hacker's Handbook cover authentication attacks thoroughly. Penetration Testing by Georgia Weidman covers credential cracking in the context of post-exploitation — useful for understanding the attacker's perspective when evaluating your own password storage choices.

SecurityClaw Scorecard: D14

D14 opens a new category in SecurityClaw's capability scorecard: password security. This complements the existing coverage — TruffleHog and Gitleaks find secrets in code and history; hashcat tests the resistance of the password hashes in your credential store.

The 59,034× speed difference between NTLM and bcrypt isn't a fine-grained performance concern. It's the difference between "cracked in milliseconds" and "economically unviable to crack at scale." It's a design choice that developers make when they choose what to call on the registration endpoint. Choose well.