Roots Team Releases wp-password-bcrypt Plugin to Improve WordPress Password Security

photo credit: Linux password file - (license)
photo credit: Linux password file(license)

This week the Roots development team released wp-password-bcrypt, a plugin that uses bcrypt instead of MD5 password hashing. MD5’s known and exploited weaknesses have rendered it “cryptographically broken and unsuitable for further use,” according to the CMU Software Engineering Institute.

In a post announcing the plugin, Scott Walkinshaw explained why WordPress’ default MD5 hashing function + salting is insecure:

MD5 is considered “broken” due to its collision vulnerability, but it’s broken more fundamentally for passwords: it’s too cheap and fast to calculate a hash.

bcrypt, on the other hand, is much slower than MD5, making it more expensive to calculate. This stronger method of password hashing is built into PHP 5.5, but WordPress maintains 5.2.4 as its minimum required version. This precludes WordPress from using the newer password_hash function.

Walkinshaw cites a four year old ticket which proposes a way for WordPress to allow plugin developers to more easily change from the salted MD5 method of hashing to the more secure bcrypt. James McKay left a sobering comment on that ticket, advocating that WordPress core move to make bcrypt the default for environments that support it:

bcrypt needs to be made the default, out of the box option on all systems that support it. The idea that WordPress admins should have to go hunting for a plugin or tweak configuration options to do this scares me, simply because most of them won’t unless (a) they are well versed in web security, (b) they know that WordPress uses a weak alternative by default, and (c) they consider it to be an issue worth worrying about.

People often underestimate the seriousness of MD5 and the SHA-* algorithms being “less secure.” They aren’t just less secure: thanks to developments in password cracking in the past few years using GPU- and FPGA- based software, they are totally useless. Programs such as oclHashCat even have an option specifically to crack passwords in WordPress databases — and the rate at which they can do so is terrifying. If you’re not making a strong password hashing algorithm the default, out of the box option, you’re exposing your users to unacceptable and unnecessary risk.

Unfortunately, action on the ticket has been held up due to a UX issue. Discussion on the ticket continues, but contributors have not yet settled on a path for improvement.

“So what is holding up the switch?” Walkinshaw said. “Bureaucracy and the unwillingness to make it happen. The consensus of the ticket is that it’s actually a UX problem. At this point, there is no technical reason why this can’t be done.”

In the meantime, if you want to implement secure bcrypt hashed passwords, you can use the wp-password-bcrypt plugin from the Roots team. It will protect against database compromises. If your WP database fell into the wrong hands, attackers would have a much more difficult time attempting to brute force a bcrypted password versus a MD5-based password.

The plugin re-hashes user passwords with bcrypt when users log in. If a user never logs in, the password remains hashed with MD5. It can also be uninstalled without negative consequences. There are no settings – it simply works in the background.

“We’ve purposely tried to keep the plugin as simple as possible so there are no surprises,” Walkinshaw said. “Obviously we recommend people test out the plugin first, and hopefully put it on a staging site first.”

The plugin can be installed by automatically autoloading it with Composer or by manually copying wp-password-bcrypt.php into your mu-plugins folder. It will also soon be added to Roots’ Bedrock project boilerplate to provide a more secure default.


  1. This is a welcome plugin, and I’ll most likely be implementing it on my sites once I’ve check it over, but what’s with the confrontational attitude from the Roots developers?

    “The WordPress core team simply doesn’t care enough about this issue to solve a UX problem which would make every WordPress site, and its users, more secure.”

    Where on the linked Trac ticket is there any suggestion that the core team, or anyone else for that matter, doesn’t care about this issue? There’s recent and ongoing discussion from multiple lead developers who quite clearly state their support for implementing bcrypt, but that WordPress cannot switch to bcrypt without first addressing the UX concern of users who migrate sites between servers that do or do not support it.

    We’re all in this together. Suggesting that the core team does not care about an issue is not productive. Let’s fix the UX concerns and then move this issue forward.


    1. I didn’t say they don’t care. I said they don’t care enough. Which is pretty obvious to me since that ticket has been open for 4 years.

      We did research on this subject, made a plugin, wrote a blog post, and have brought attention to this issue which is all productive.


      1. WordPress core is a community effort. Unless someone steps up and takes charge of an issue, it won’t get solved.

        Want your plugin or any other fixes implemented? Participate in the weekly core meetings on Slack. Contribute code, time, solutions, UX tests & findings, etc.

        The “core team” is YOU.


      2. What a BS. You need a commiter’s agreement in order to get code into core. Core is developed by the commiters to serve whatever needs they think worth serving, it is not a community development effort. (to be clear I don’t have any real problem with this structure, but to tell people like they just can write code and it will get into core is just stupid)


    2. I’ll believe it when I see it.

      If someone doesn’t feed their dog for a week, I will have it on good authority that they don’t care enough about that dog. How much they say they care doesn’t matter.


      1. As a member of the WordPress community, this is your dog too. Do you care about your dog? If so, you should contribute to the trac ticket with your ideas on how to solve that UX issue.

        That’s the best way to move forward. Commenting here, being confrontational with the people who show up and contribute to WordPress, doesn’t “feed the dog”. How much you say you care doesn’t matter.


      2. So it’s our dog too, Jeremy, is it? But only so long as we feed it only in the way you tell us to?

        Doesn’t work, does it?

        Some years ago, my wife’s parked car was badly damaged by a truck driver. While we got the car repaired, I wrote to the trucking company, explaining what had happened and asking politely that they pay the bill, for which I supplied the garage’s estimate. After some delay, they wrote back and declined.

        So then I wrote them a much more confrontational letter, detailing the full cost that we had, by then, paid. They replied almost immediately, complaining about my unpleasant tone … and enclosing a check for the full amount.

        When politeness has been tried and doesn’t work, sometimes confrontation is necessary. Those complaining about the confrontational tone are then hardly in a position to complain (though it’s sometimes amusing when they do).


  2. I have rolled this out after some testing across all my sites. I think the frustration of supporting EOL versions of php is fair a call. PHP 5.2 has been EOL for 5 years and 1 month. The time to move on and bump the minimum supported php version came a long time ago.


  3. Three years ago, I suggested that once WordPress upgrades it’s PHP requirement to 5.3, then the switch should be made. The hold up here in my opinion is not this ticket about passwords, but related ones asking for the PHP version to be increased, which in turn are preventing the password ticket from being processed.


  4. Well, it seems to be working OK by just dropping it into /mu-plugins/ folder BUT, not being a cryptographer, I could be kidding myself I have done something positive for the security of my site, because I have no way to tell if it’s working or not.


    1. If you look in the database at the password hash, you should be able to see that it looks different from the default ones I think.


      1. Yes, that is indeed the case. With the plugin dropped in the mu folder the password hash becomes twice as long basically and completely different from the MD5 hash.


  5. Backward compatibility vs. security.. that’s amusing. Four years, that’s not long … really.. is it?

    Thanks for this post.


  6. If I install this plugin and later decide to remove it, will it mess up my login?


    1. The library that WordPress uses can handle bcrypt hashes. WordPress core goes out of their way to prevent the library from using it during hash creation, but it will fallback to it during verification.

      If any of that was confusing, then I’ll put it simply: No, it will not mess up your logins. They will continue to work even after removing the plugin. But the next time you create/change your password, the bcrypt hash will no longer be used.


  7. I have installed this on a couple of sites, and it seems to be working fine. I can see the different style of password hashes in the database, and logins, etc to continue to work as before. So all good.

    I am wondering, though, why the pull request here hasn’t been warmly received. To a non-coder like me, it seems a good idea to build in some future-proofing, and the proposer argues that it has no downside. Is that right?


  8. Hi, thanks for this article on improving the password safety for wordpress sites.

    I’m not a developer, just a wordpress user so hopefully someone can answer this.

    At the github site it mentions you need to have PHP 5.5.0 for this plugin to work, but I’m not sure how to know if I have this or not. Is this something that would be within wordpress, or is it my host? Or maybe it’s something I should have on my computer while installing the plugin?

    Thanks in advance for your help. I have things like wordfence running, and use 35 character random passwords to try and keep it secure, but it appears I should be implementing this plugin as well or the rest could be for nothing.

    Anyway, thanks again.


    1. Hi Tracy,

      If you are on a shared hosting plan (I assume you are) you should write to your hosting provider and they can tell you which version of the PHP you are using now and also they can move your site to PHP 5.5.0 or later (5.6.0 is preferred).

      You cannot change the PHP within WP itself.



      1. Thank you Primoz Cigler and Knut Sparhell, I appreciate your responses. I’ll look into it today and see what I can do. I’ve already had a site hacked a couple of times and taken precautions to prevent it and this just seems like something I better do to help ensure it doesn’t happen again, lol.


Comments are closed.