At 2:14 AM, a client pinged me with the kind of message that makes your stomach drop: “Logins are working, but our custom auth plugin is throwing warnings after the update.” Traffic was fine. Admin access was fine. Nothing looked broken from the outside. But under the hood, password handling had changed, and one old assumption in a plugin had turned into a production risk.

That night was my reminder that the WordPress 6.8 security update is not dramatic, but it is meaningful. WordPress moved default user password hashing from legacy phpass behavior to bcrypt-based handling through core APIs. If you run custom auth code, SSO bridges, membership plugins, or direct database checks, this is worth a real rollout plan, not a casual “click update and move on.”

This guide is the playbook I now use for WordPress bcrypt password hashing rollouts on production sites, with the tradeoffs spelled out.

The change in plain English (and why it matters)

WordPress core now uses modern PHP password APIs in wp_hash_password/wp_check_password paths, and keeps compatibility for older stored hashes. Existing users do not need forced password resets just because you upgrade. Rehashing happens gradually as users authenticate again.

The practical upside is stronger default resistance against offline cracking compared with old portable hash patterns. The practical downside is that any plugin or integration that assumes one fixed hash prefix or old hash shape can misbehave.

So the real work is not “Can users log in?” It is “Do all auth-adjacent integrations still behave correctly while hashes transition over time?”

Before you touch production: run a compatibility audit

I start with an audit of user hash formats, plugin behavior, and login-path latency. Not because WordPress core is fragile, but because old assumptions in custom code often are.

1) Inspect current hash distribution

# Run on the WordPress host
wp db query "
SELECT
  CASE
    WHEN user_pass LIKE '$wp$2y$%' THEN 'wp-prefixed-bcrypt'
    WHEN user_pass LIKE '$2y$%' THEN 'bcrypt'
    WHEN user_pass LIKE '$P$%' THEN 'phpass'
    WHEN user_pass REGEXP '^[a-f0-9]{32}$' THEN 'legacy-md5'
    ELSE 'other'
  END AS hash_type,
  COUNT(*) AS users
FROM wp_users
GROUP BY hash_type
ORDER BY users DESC;
" --skip-column-names --allow-root

This gives you a migration baseline. You are not changing passwords in bulk, you are measuring how long your mixed-hash period may last.

2) Find code that bypasses core password APIs

# Scan plugins/themes for risky patterns
grep -R --line-number --perl-regexp "user_pass|\$P\$|password_verify\(|md5\(|wp_set_password\(" wp-content/plugins wp-content/themes

# Then manually verify any direct hash checks
# Goal: route checks through wp_check_password() where possible.

If a plugin is doing direct string-prefix logic against user_pass, put it on your watch list first.

The rollout model I trust: Observe, update, verify, then optimize

Phase A, Observe

• Take a fresh DB backup.
• Capture current login success rate and median login response time.
• Record active auth plugins and any SSO/custom login hooks.

Phase B, Update and verify core flows

• Update WordPress core in a staging environment first.
• Test: wp-login, XML-RPC/app passwords (if enabled), password reset, admin session continuity.
• Check logs for plugin warnings tied to hash parsing or auth hooks.

Phase C, Controlled production rollout

• Deploy in a lower-traffic window.
• Watch login error rate and CPU behavior for 30 to 60 minutes.
• Keep rollback path ready for plugin-level regressions, not for the hashing model itself.

If your site already has a careful plugin rollout discipline, reuse it here. I use the same guardrails described in this WordPress extensibility runbook, then add auth-focused checks.

Performance tradeoff: stronger hashes vs login latency

Teams often ask this immediately: “Will logins become slower?” The honest answer is: they can become a bit slower per attempt, and that is expected for stronger password work. What matters is whether your infrastructure and abuse controls can absorb the cost safely.

For high-volume sites, pair this change with rate-limiting and bot controls. If your PHP workers are already close to saturation, fix that first. The PHP-FPM triage steps from this PHP-FPM runbook help you verify capacity before peak traffic.

Could you push algorithm/cost customization through WordPress filters? Yes, but that is a deliberate security-performance decision, not a “tweak because someone said so” move. I only touch it after measuring real login-path impact in production-like load tests.

Troubleshooting: what fails in real migrations

Symptom: users can log in, but auth plugin throws notices

Likely cause: plugin assumes legacy hash prefix or inspects hash internals directly.
Fix: update plugin logic to use wp_check_password() and rehash decisions through core wrappers instead of prefix assumptions.

Symptom: sudden login CPU spike after release

Likely cause: expected increase in password-verification cost combined with bot traffic or thin PHP capacity.
Fix: enforce login throttling/WAF rules, review PHP-FPM pool sizing, and confirm no accidental login retry loops.

Symptom: custom SSO bridge marks valid local credentials as invalid

Likely cause: bridge compares stored hashes directly instead of delegating to WordPress auth functions.
Fix: route through WordPress auth APIs and remove hash-format coupling.

Security hardening is a system property, not a single toggle. If your review process still treats auth, infra, and plugin code separately, you get blind spots. This is exactly the kind of control-integrity gap discussed in this hardening playbook and in the cookie/session edge cases from this website security guide.

What I avoid during this migration

I do not force mass password resets unless there is another security reason (for example, known credential compromise). For most sites, forced resets create support load, increase lockouts, and do little to improve security if there is no active breach signal.

I also avoid one-click “optimization” snippets that change hashing behavior globally without staging tests. Authentication is too central to gamble on copied code. If you adjust filters around algorithm or options, test with real plugins, test password reset flow, and test every place your stack authenticates users, including app passwords and admin APIs.

Finally, I do not treat the migration as done on release day. You should monitor hash-type mix and login-path errors for a few weeks, because rehashing is event-driven by user activity. Quietly watching this transition is usually what separates smooth upgrades from 3 AM surprises.

FAQ

1) Do I need to force every user to reset passwords after upgrading?

No. Existing hashes remain valid, and password rehash on login happens progressively as users authenticate again.

2) Should I switch immediately to Argon2 everywhere?

Only if your hosting stack consistently supports it and you have tested behavior end-to-end. Bcrypt defaults are already a meaningful step forward, and consistency across environments matters more than theoretical best-case settings.

3) Can I bulk-convert all hashes in advance?

Not safely without plaintext passwords, so no in the normal case. The standard approach is opportunistic rehash during successful authentication and password changes.

Actionable takeaways

• Treat WordPress 6.8 password hashing as a controlled auth migration, not a cosmetic update.
• Audit plugins for direct hash assumptions before production rollout.
• Measure login latency and CPU under realistic traffic, then decide whether tuning is necessary.
• Use WordPress auth APIs consistently, avoid direct hash parsing in custom code.
• Track migration progress by hash-type counts over time until legacy formats become negligible.

If you run modern WordPress seriously, this is the right mindset: small core security improvements are where long-term incident prevention usually starts.