WordPress Password Hashing Changed: What Bcrypt in Core Means for Site Security and Hosting Checks
WordPress 6.8 changed a core security behavior that many site owners will never see in the UI but should still understand: standard user account passwords are now hashed with bcrypt, and application passwords use BLAKE2b.
That is a solid security improvement, but the operational point matters more than the cryptography lesson. If your site uses normal WordPress login and password reset flows, this should be low-friction. If you have custom authentication code, direct database writes, old integrations, WooCommerce account customizations, SSO bridges, or headless systems that make assumptions about stored password formats, this update deserves a quick audit.
According to the WordPress core announcement and the WordPress 6.8 release documentation, existing user passwords are not all rewritten at once during upgrade. In most cases, they move to the new hashing approach when a user successfully logs in or resets their password. That means you can have a mixed state for a while: old hashes still verifying for some accounts, newer hashes appearing as users authenticate and passwords get re-saved through core.
What changed in WordPress 6.8
WordPress core now uses bcrypt for standard user passwords through its supported password APIs. Application passwords are handled separately and use BLAKE2b, not bcrypt. That distinction matters for anyone building custom integrations around remote access, API connections, or account tooling.
The practical compatibility story is also important. Core verification functions are designed to keep older stored passwords working, then move accounts forward over time through successful login or password reset flows. WordPress developer references for wp_hash_password(), wp_check_password(), and wp_set_password() make the intent clear: use core functions and let WordPress manage hashing, verification, and updates.
Where this can break is not core login itself, but custom code around it. Risk areas include plugins or custom snippets that inspect hash prefixes, compare hashes manually, write directly to wp_users, sync passwords into external systems, or bypass core password functions during account creation, reset, import, or migration. Those shortcuts were always brittle. They are more obviously brittle now.
For WooCommerce operators, this mostly shows up in customer account logins, password reset emails, checkout account creation, and any custom my-account or portal behavior. For agencies and internal teams, staging and production parity matters too. If staging is running a different PHP stack or an older hosting image than production, auth testing can give you false confidence.
What to do next
First, confirm the obvious: your site is actually on WordPress 6.8 or later, and your hosting environment is current enough to support normal core behavior. This is not a special server tuning project, but it is a good excuse to verify PHP currency and remove outdated assumptions from deployment docs.
Then run a short test list on staging before calling the upgrade complete:
-
Test normal wp-admin and front-end user login.
-
Test password reset from the real email flow through successful login.
-
Test WooCommerce customer login, account creation, and reset flows.
-
Test any application password use cases, especially for API-connected tools.
-
Test custom portals, membership flows, SSO bridges, and headless front ends that authenticate against WordPress users.
Next, search your codebase and mu-plugins for anything touching password handling directly. Red flags include direct updates to the user_pass field, manual calls outside core auth functions, logic that checks stored hash format, or middleware that tries to “help” WordPress by pre-hashing values.
If you find custom auth logic, the safest direction is usually to refactor toward core APIs instead of patching around the new formats. That reduces maintenance burden and lowers the chance of subtle login failures after future updates.
One last caution: bcrypt in core is a real improvement, but it does not make account security automatic. Patch discipline, plugin quality, role hygiene, MFA policy, admin access control, and recovery workflows still decide how exposed your site really is. The upgrade is good news. The follow-through is where the operational value shows up.
Sources
- WP core bcrypt announcement
- WordPress 6.8 release notes
- wp_hash_password reference
- wp_check_password reference
- wp_set_password reference
- PHP password_hash docs
- Search Engine Land context
Know someone who would benefit from this update? Share this article with them.
This article is for informational purposes only and reflects general marketing, technology, website, and small-business guidance. Platform features, policies, search behavior, pricing, and security conditions can change. Verify current requirements with the relevant platform, provider, or professional advisor before acting. Nothing in this article should be treated as legal, tax, financial, cybersecurity, or other professional advice.
