John Blackbourn: Hi everyone, my name is John Blackbourn. I am the WordPress core security team lead and a longtime contributor to the WordPress open-source project. I hope you’re enjoying the Cloudways WordPress Security Bootcamp so far. I’m going to talk today about two topics. Firstly, the security enhancements that will be released soon in the next version of WordPress, and secondly, some improvements that have been made to the software supply chain for the WordPress open-source project, and how both of those changes can help website owners maintain a more secure website. So let’s take a look.

The next major version of WordPress will be version 6.8, which is due to be released in April. One of the security related changes in this version is to the way that user passwords are stored in the database, in order to increase their security. This is a technical change to the underlying algorithm that is used to convert a password from its plain value into something that’s safe to store in the database. And this is a notable change because the way that a password is stored in a database is very important.

The password can’t be stored in plain text, because that would mean if somebody were to gain access to your database they would be able to see the value of all of the passwords. A password needs to be stored in a cryptographically secure method, which means if someone were to gain access to your database they would not be able to reverse engineer that value in order to discover the actual value of the password.

Now you might be thinking, well how could that happen, how might somebody gain access to the database for my website, and if they do, surely I have a bigger problem to worry about than my password. Well there are a few ways that this might happen. One common one is a misplaced database backup. How many times have you taken a backup of your database and stored it somewhere else, or downloaded it to your computer, or accidentally left a backup laying around on the file system on your website? All of these are opportunities where an outside factor could result in somebody getting access to a copy of your database, even if they don’t have live access to your current database. And this is why protecting the value of passwords stored in the database is important, as it prevents passwords from being discovered and then used to log into your website, or indeed to log in anywhere else that you’ve used the same password, which you shouldn’t be doing.

So in WordPress 6.8 the underlying mechanism that’s used to securely store a password is being updated to BCrypt, which is the industry standard for creating a cryptographically secure hash of a password. If somebody were to gain access to your database, or a copy of a backup of your database, they would not be able to reverse engineer a stored password value in order to discover the password itself. The password storage mechanism used in WordPress prior to version 6.8 is still secure, but BCrypt increases this security by a couple of orders of magnitude, and this sets us up well for the future as the capabilities of computers continue to increase and we need to continue protecting stored passwords.

So why is all of this important? Surely if nobody accesses your database then none of this matters. Well, you may have heard the term defense in depth. Unfortunately it’s not possible to just press a button and make every aspect of your website secure. Security is only achieved by combining measures and continually improving, and this is one of those improvements that, when combined with other security best practices, helps maintain the overall security of your website and its data.

Now the neat thing about this change is that it’s entirely invisible. If you’re the owner of a WordPress website and you update it to version 6.8, there is nothing at all that you need to do. Users don’t need to change their password to take advantage of the improved password storage mechanism, it will just happen behind the scenes the next time they log in. In fact you could forget about everything I’ve just said, and after updating to WordPress 6.8 the security of each of the passwords stored in your database would be increased as each user subsequently logs in again.

Now all that said, it’s important to note that this change doesn’t mean that a weak password becomes more secure. One of the easiest and most important aspects of keeping your website secure is to use strong passwords to begin with, but hopefully you don’t need me to tell you that. If you want to read more about the technical information behind this change, then you can find all the information in the post about this change on the WordPress development site at make.wordpress.org. I will ask the folks at Cloudways to include the link so you can read more information about this change if you wish.

So the second thing I wanted to talk about is an area that in a lot of ways gets less attention than it should, which is the security and reliability of the supply chain that is involved in creating the software that’s used on your website, whether that’s the WordPress core software or the plugins and themes that you use. Modern software development processes include a lot of automated aspects, whether that’s automated testing, developer tooling for dependencies, or running scripts to build and package the software for release. And the security of this tooling and these processes is often just as important as the security of the software itself and the security of the websites that it’s used on, because ultimately they’re all involved in the creation of the software. If there was a security vulnerability in any of these processes or tools, then it could allow malicious code to get surreptitiously included into WordPress or plugins or themes.

This isn’t a new problem, but in recent years there have been a few high-profile instances in other ecosystems where the developer tools that are used in the creation of the software was compromised and it resulted in malicious code being included in the published packages. There have been a handful of instances of this within the WordPress ecosystem in recent years, luckily nothing too bad, but it did end up in malicious code being published in a plugin without the developer’s knowledge. Such compromises are usually only discovered by security researchers who identify the malicious code, and then the plugin developers have to release an update.

So why do I mention this? Well, some renewed efforts have been made in recent months to ensure that the software supply chain of WordPress itself remains as strong as it can be. One of those is an improvement to the GitHub Actions workflows that are used by the WordPress organization on GitHub. GitHub Actions use automated workflows that perform all sorts of testing, packaging and deployment of the various aspects of WordPress. This includes the core software and the block editor. The security team for WordPress have assessed and hardened a whole bunch of aspects of these workflows in recent months to ensure that they’re as secure as can be, and to reduce the potential for vulnerabilities to be introduced to the software via its supply chain.

I’m not going to go into the details now because it is very technical, but if this is something that sounds interesting to you, then you might like to take a look at a resource that I maintain called awesome GitHub actions security. And supply chain security in general is a fascinating topic, but within the WordPress ecosystem, the security specifically of GitHub Actions that are used by the WordPress core team and the developers of plugins and themes is a particularly important aspect. So take a look, and as I said, if this is something that interests you, then there’s a whole bunch of resources and reading on this topic, and hopefully something there that you will find interesting.

That’s all I have time for today. I hope you all enjoy the rest of the Cloudways WordPress Security Bootcamp. If you have any questions feel free to get in touch, I’m on LinkedIn, if you search my name on there you’ll find me. And thanks very much for watching. Bye for now.