---
title: "WordPress 6.8 Makes bcrypt the Default: What to Do with wp-password-bcrypt"
url: "https://helloblog.io/wordpress-6-8-bcrypt-default-wp-password-bcrypt-sunset/"
date: "2025-02-20"
modified: "2026-01-20"
author: "Emma Richardson"
language: "en_US"
categories: ["WordPress Ecosystem"]
tags: ["Authentication", "Bedrock", "php"]
featured_image: "https://helloblog.io/app/uploads/2026/01/featured-7-1024x572.jpg"
excerpt: "WordPress 6.8 moves password hashing forward by adopting bcrypt in core. If you’ve been using the wp-password-bcrypt package, you can now simplify your stack—without breaking existing logins."
---

# WordPress 6.8 Makes bcrypt the Default: What to Do with wp-password-bcrypt

For years, one of the most common “modern WordPress hardening” upgrades was swapping WordPress’s legacy password hashing for bcrypt. With WordPress 6.8, that upgrade is no longer something you need to bolt on—bcrypt becomes the default password hashing method in core.

That change has a nice side effect for teams running Roots/Bedrock stacks: the `wp-password-bcrypt` package is effectively obsolete on WordPress 6.8+ and can be removed cleanly.

## What changed in WordPress 6.8 (and why it matters)

A password “hash” is the one-way representation of a password stored in the database. When a user logs in, WordPress hashes the submitted password and compares it to the stored value. Historically, WordPress used hashing approaches that were functional but no longer considered best practice in modern application security.

bcrypt is a widely adopted password hashing algorithm designed specifically for passwords. It’s intentionally slow and supports a configurable work factor, making brute-force attacks significantly more expensive. By moving bcrypt into core starting with WordPress 6.8, WordPress sites get stronger baseline authentication security without needing extra plugins or Composer packages.

## Why wp-password-bcrypt is being sunset

Roots created [`wp-password-bcrypt`](https://github.com/roots/wp-password-bcrypt) to bring bcrypt-based hashing to WordPress before it existed in core. It did its job: many modern WordPress deployments used it as a “set it and forget it” security improvement.

Now that WordPress itself handles bcrypt in 6.8+, the package no longer provides meaningful value for sites on current core versions. Maintaining an extra dependency for something core already does is unnecessary surface area—more updates to track, more places for subtle compatibility issues, and more complexity during upgrades.

## If your site runs WordPress 6.8+, you can remove it (no migration required)

The key operational detail: if you’re on WordPress 6.8 or later, you can safely remove `wp-password-bcrypt` and existing user passwords will continue to work. There’s no special “rehash everything” migration step required, and you shouldn’t need to reset user passwords as part of this change.

#### Practical takeaway

On WordPress 6.8+, uninstalling/removing `wp-password-bcrypt` should be a routine dependency cleanup, not a risky authentication change.

## What Roots is doing to reflect the change

Roots is aligning its ecosystem with WordPress core by winding down the package. According to the announcement, the project will be marked as abandoned on Packagist, references will be removed from Bedrock and related documentation, and the GitHub repository will be archived.

## Recommended cleanup steps for Bedrock/Composer projects

If your WordPress codebase is Composer-managed (for example with Bedrock), treating this as dependency hygiene is the right mindset. The goal is to ensure you’re actually running WordPress 6.8+ in production before removing the package, then delete the dependency and deploy as usual.

1. Confirm the production environment is running WordPress 6.8 or later.
2. Remove `roots/wp-password-bcrypt` from your Composer dependencies.
3. Deploy and verify logins for a few representative user roles (admin/editor/subscriber).
4. If you have custom authentication code (SSO, XML-RPC edge cases, custom login endpoints), run through those flows as part of a normal regression pass.

If you’re maintaining multiple WordPress installs at different versions, keep the dependency only where it’s still needed. The simplest rule is version-based: WordPress \< 6.8 may still benefit from the package; WordPress 6.8+ does not.

## Bigger picture: a meaningful baseline security win

This is one of those rare platform changes that improves security for almost everyone automatically. Teams that already cared about password hashing can remove an extra moving part, and teams that didn’t get a stronger default without changing their workflow.

If you’ve historically used `wp-password-bcrypt` as a “minimum standard” on client projects, WordPress 6.8 is the point where that standard becomes native.

## References / Sources

- [Sunsetting wp-password-bcrypt with WordPress 6.8](https://roots.io/sunsetting-wp-password-bcrypt-with-wordpress-6-8/)
- [WordPress 6.8 will use bcrypt for password hashing](https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/)
- [roots/wp-password-bcrypt](https://github.com/roots/wp-password-bcrypt)