In WordPress 6.8, the internal algorithm used to hash and store user passwords in the database switched from “phpass portable” (an MD5-based scheme with a fixed work factor) to bcrypt, a Blowfish-based algorithm with a configurable cost factor.
In one of my recent talks, to demonstrate how much more difficult it is to crack a hashed password generated with bcrypt by brute force, I pasted a hash into an online “strength checker” like PasswordMonster—which reports how long it would take to brute-force that hash in years.
However, as one colleague pointed out:
“It doesn’t really make sense to paste a password hash into the strength checker. That tool checks the strength of the plaintext password. To test hashing security you’d do a benchmark to see how long it takes to generate hashes, not rainbow tables.”
When I received that feedback, I thought to myself, “Oh my God—that’s absolutely right; I’ve mixed concepts here.” In Developer Relations, we sometimes have to talk about topics outside our field of expertise, so slip-ups like this may happen. I really appreciate my colleague’s feedback—it helps me learn and grow.
So let’s do this right…
In this post I’ll explain why online strength checkers are misleading for hashed passwords, and show how to accurately benchmark and compare password-hashing algorithms like phpass or bcrypt.
Table of Contents
- Does a longer password hash make it harder to crack?
- Why online strength checkers don’t measure hash security
- A good methodology to check hash security
- Conclusion
Does a longer password hash make it harder to crack?
Hashes generated with wp_hash_password in WP 6.8
⬢ my-wp-site wp shell
wp> get_bloginfo('version');
=> string(5) "6.8.1"
wp> wp_hash_password("my_password")
=> string(63) "$wp$2y$12$RnJgFT5Ooe6P0ajs/eaCYuqKLwWEqkZd01j2JyyrF6mcZa8NHJTxu"generates a longer hash than the same function in WP 6.7
⬢ my-wp-site wp shell
wp> get_bloginfo('version');
=> string(5) "6.7.2"
wp> wp_hash_password("my_password")
=> string(34) "$P$BG2Xi5wQWVhdZmqnLmtkcrmlCT8wTc."but… does a longer password hash make it harder to crack?
A password hash is like a locked box holding a secret: no matter how big the box looks on the outside (how many characters the hash has), that size doesn’t make it any harder to pick. What really protects the secret inside is:
- how random the password is,
- how slowly the lock turns,
- and whether each lock is unique.
First, a complicated, random password (high entropy) is like using a key with a wild, unpredictable pattern—far tougher for a thief to guess than a simple word. Second, modern hashing methods (bcrypt, Argon2, PBKDF2) add deliberate delays. Each guess you try takes extra time, so trying millions of passwords becomes impractically slow. Third, adding a unique “salt” to every password is like engraving each lock with its own custom mark. Even identical passwords end up with totally different hashes, so attackers can’t break many at once using one master trick.
In contrast, simply making the hash string longer is like painting a bigger box: it may look more intimidating, but it doesn’t actually slow down the thief’s tools. What matters is how hard the key is to guess, how slowly the lock works, and how uniquely each lock is made—those are the real defenses against someone cracking your password.
Why Online Strength Checkers Don’t Measure Hash Security
Tools like PasswordMonster evaluate the complexity of a plaintext password (length, character variety, patterns). So they’re not useful to measure the security of the hash of a password as they don’t account for:
- The computational cost of generating or inverting the hash
- Real-world hashing speed on modern hardware (CPU/GPU)
- The effect of configurable work factors or per-password salts
To assess resistance to brute-force, we must measure how many hashes per second your hardware can compute, then estimate how long a full search of the keyspace would take.
A good methodology to check hash security
To evaluate hash security, we can use a cracking tool to determine how difficult it is, on a specific machine, to break a hash generated by a given algorithm for a particular type of password.
Benchmarking
hashcat is the industry-standard cracking tool for GPU/CPU. With this tool we can measure how many hashes our computer can process per second.
On a Mac we can install it by doing
brew install hashcatHashcat’s --benchmark (or -b) mode measures how many hashes per second (H/s) your machine can compute for each algorithm.
To check how many hashes per second our machine can compute for phpass and bcrypt, we can launch the following commands:
# phpass portable (MD5-based) = mode 400
hashcat -m 400 --benchmark
# bcrypt Blowfish = mode 3200
hashcat -m 3200 --benchmarkhashcat can provide benchmarks for almost any existing algorithm. Each algorithm has its own code as displayed in this table. In the commands above, 400 is the code for phpass and 3200 the code for bcrypt
On my Mac I get the following numbers:
- phpass (mode 400): ~5427 kH/s
- bcrypt (mode 3200): ~19 kH/s
kH/s means thousands of hashes computed per second
These numbers alone already tell that bcrypt is far more resistant to brute-force than phpass. bcrypt is ~300× slower to compute per hash which makes it much more difficult to crack (each try takes more time). bcrypt turns a matter of days into years or decades—exactly what you want in a password‐hashing algorithm.
How long a brute-force attack would take against either hash
Once we have measured our computer’s hashing throughput in hashes-per-second (H/s) for both phpass and bcrypt, we can quantify exactly how long a brute-force attack would take against either hash. Here’s how:
1. Define the keyspace
The keyspace is the total number of possible passwords an attacker must try. For example, if your policy allows 8 characters drawn from lowercase letters a–z (26) plus digits 0–9 (10), then:
Keyspace = 36⁸ ≈ 2.8 × 10¹² guesses- 36 is your alphabet size (26 letters + 10 digits)
- 8 is your password length.
- 36⁸ multiplies the number of options for each of the 8 slots.
- 36⁸ = 2 821 109 907 456 distinct passwords.
- 2 821 109 907 456 ≈ 2.8 × 10¹² which means 2.8 trillion guesses when there’s a total number of 8-character strings possible.
With these calculations, even a “small” increase in password length or symbol set size explodes the keyspace (e.g., 9 characters ⇒ 36⁹ ≈ 101 559 956 668 416, over 100 trillion possibilities!).
2. Pull in the benchmark rates
From the benchmarking in my computer I got:
- phpass (mode 400): ~5427 kH/s
- bcrypt (mode 3200): ~19 kH/s
These numbers tell you how many password hashes per second my Mac can compute for each algorithm.
3. Compute total attack time (worst-case scenario)
The worst-case time to exhaust the entire keyspace is simply:
So for phpass:
t_phpass_sec = 2.8e12 ÷ 1.8e4 ≈ 1.56e8 secondsAnd for bcrypt:
t_bcrypt_sec = 2.8e12 ÷ 3.0e2 ≈ 9.33e9 seconds4. Convert seconds into human units
Divide by 3 600 to get hours, then by 24 for days, and by 365 for years:
phpass
t_phpass_hours = 1.56e8 ÷ 3600 ≈ 43 333 hours
t_phpass_days = 43 333 ÷ 24 ≈ 1 805 days (~4.9 years)bcrypt
t_bcrypt_hours = 9.33e9 ÷ 3600 ≈ 2.59e6 hours
t_bcrypt_days = 2.59e6 ÷ 24 ≈ 108 000 days (~296 years)So in a worst case scenario (whole time to exhaust the entire keyspace is needed), for a password of 8 characters drawn from lowercase letters a–z, plus digits 0–9, it would take ~4.9 years to crack the hash of a password generated with the phpass algorithm and ~296 years to crack a hash for the the same password generated with the bcrypt algorithm
Average-case vs. worst-case: On average an attacker finds the password in half this time—still ~2.45 years for phpass vs. ~148 years for bcrypt1
Conclusion
- phpass @ 18 000 H/s → ~4.9 years to brute-force every 8-char password.
- bcrypt12 @ 300 H/s → ~296 years to do the same.
This quantitative gap—years vs. centuries—demonstrates exactly how much more resilient bcrypt (with cost=12) is compared to the old phpass scheme. By plugging your own H/s and keyspace values into these formulas, you can reproduce the proof on any machine.
WordPress 6.8’s adoption of bcrypt represents a huge milestone, aligning the platform with today’s strongest password-storage standards. In this article, we have compared (using a solid methodology) the enhanced security of bcrypt-generated hashes against the legacy phpass algorithm used in earlier WordPress releases.
Leave a Reply