Most WordPress upgrades are judged by what editors notice in the admin. This one is different. WordPress 6.8 changed how user passwords and several security-sensitive tokens are hashed and verified. For normal sites that use standard WordPress login, that is mostly good news: security is stronger and existing users keep working. The real risk sits in the custom code around WordPress, especially older login bridges, SSO glue code, migration helpers, mobile APIs, and support scripts that inspect stored hashes directly.
If your team has ever compared credentials against wp_users.user_pass, looked for a $P$ prefix, read wp_users.user_activation_key, or validated application-password data outside WordPress core, this is worth a staging review. These failures rarely appear on upgrade day. They show up later, when one account logs in, one password reset runs, or one integration finally meets a new-style hash.
What changed in WordPress 6.8
For user passwords, WordPress 6.8 moved the default hashing path to bcrypt via wp_hash_password() and wp_check_password(). Core pre-hashes the password with SHA-384 before bcrypt so long passwords are handled safely, then stores the value with a $wp prefix. In practice, new core password hashes usually begin with $wp$2y$.
WordPress also introduced a separate fast-hash path for high-entropy secrets such as application passwords, password reset keys, personal data request keys, and recovery mode keys. Those values now use the $generic$ format and are meant to be verified with wp_verify_fast_hash().
The important operational detail is that core kept backward compatibility. Older phpass hashes still validate. Existing users are not forced to reset passwords, and a password is only rehashed after a successful login or password change. That is helpful for end users, but it also hides broken assumptions in custom code. Core may be fine while the bridge around it is not.
Where the breakage usually lives
The common failure pattern is not that WordPress login breaks everywhere. It is that a custom auth path breaks quietly. The risky examples are familiar:
- A portal, API, or middleware service checks
user_passitself instead of calling WordPress. - A plugin or script assumes every WordPress password hash starts with
$P$. - An integration reads
_application_passwordsoruser_activation_keyand applies its own verification logic. - Legacy code still uses
md5(), rawpassword_verify(), or an embeddedPasswordHashclass against WordPress data. - A plugin overrides the pluggable password functions to preserve older behavior.
WordPress core explicitly notes that alternative login methods such as SSO, social login, one-time login, MFA, and 2FA are unlikely to be affected by the hashing change itself. The catch is the surrounding glue code. If your implementation reads or verifies stored values directly, it still needs review.
This is what makes the issue expensive. The problem often stays invisible until one user record has been rehashed, one reset key uses the newer format, or one external service hits a branch of code nobody has tested in months. That is how a sensible security improvement turns into a paid troubleshooting problem for agencies and in-house teams.
What a proper fix looks like
The practical fix is not to teach every custom component about every hash prefix WordPress may ever store. The safer approach is to stop handling WordPress hashes directly and let WordPress own the compatibility logic.
// User passwords
if ( wp_check_password( $password, $stored_hash, $user_id ) ) {
// authenticated
}
// Application passwords, reset keys, recovery keys, and similar secrets
if ( wp_verify_fast_hash( $token, $stored_hash ) ) {
// valid secret
}
// Refresh older hashes through supported core logic
if ( wp_password_needs_rehash( $stored_hash, $user_id ) ) {
// re-save the password through WordPress
}If a plugin or custom package has deliberately changed the hashing algorithm, review that choice too. WordPress allows filters for alternatives such as Argon2, but that is not universally available on every PHP build. If you did not choose it on purpose, do not assume it is safe to rely on.
How to audit a live codebase quickly
For agency teams and operations leads, the fastest first pass is a targeted code search. These patterns are worth reviewing before the next release window or migration:
rg -n "\$P\$|user_pass|user_activation_key|_application_passwords|PasswordHash" wp-content/
rg -n "md5\(|password_verify\(|password_hash\(|wp_hash_password|wp_check_password" wp-content/Then trace any custom API, SSO adapter, member portal, migration bridge, or support utility that touches authentication data. If a non-PHP service validates WordPress credentials, treats database values as stable contract data, or copies reset-key behavior outside core, assume it needs review until proven otherwise.
What to test before users do it for you
On staging, test one account that still has an older hash and confirm the first successful login works. Then test the same account again after WordPress has had a chance to rehash the password. Test password changes, password resets, application passwords, and any recovery or privacy-request flows you have customized.
If your business uses SSO, a CRM portal, a mobile app, or a bridge between WordPress and another identity system, test those paths separately. A successful admin login is not enough evidence. You need to verify the places where custom code touches stored auth data or security keys.
Why this deserves proactive work
Authentication bugs are awkward to diagnose, easy to miss in casual QA, and very visible once real users hit them. WordPress 6.8 itself did the right thing. The risk is in old shortcuts that treated internal hash formats as permanent infrastructure.
If you want a practical review instead of a bigger rebuild, Greg can audit the custom code around WordPress login, reset flows, and application passwords, replace raw hash handling with supported core functions, and help your team test the exact paths that tend to fail late. That is usually cheaper than diagnosing a lockout or broken bridge after it reaches production. Talk to Greg about a targeted WordPress auth audit.
Need help with this kind of work?
Talk to Greg about a short WordPress authentication audit before an old login bridge turns into a production support issue. Get in touch with Greg.