What Are The Next Steps in WordPress Security?

Hi, this is David McCann for WebTNG. In this article I’m looking at WordPress security and sharing some ideas to improve it. I’ve been thinking a lot about this topic.  If you’ve been managing WordPress websites then I imagine you’ve also been thinking about it. It’s pretty hard to miss these days. When I log in to my WordPress sites I see small red alert circles telling me about vulnerabilities. When I log into my email, I get emails from PatchStack, SolidSecurity, Wordfence, Mal-Care, and maybe others telling me about plugin vulnerabilities. In fact, this week’s email from Wordfence listed 375 items! When I go on social media there are discussions about vulnerabilities and how developers are responding to them. When I check tech blogs online there are public service announcements alerting me to the fact that there are plugins with more than a million active installs that have vulnerabilities. These days, WordPress security is pretty hard to ignore. 

Audio Version

Asking the Inconvenient Question

I started to feel that WordPress security is going off the rails, that we need to make some kind of adjustments. What can we do? As I gathered together thoughts about WordPress security I asked myself the inconvenient question, “Is WordPress secure?” For years and years, the often repeated wisdom is that WordPress is secure and users just need to keep everything updated and follow some best practices to keep their sites from getting hacked. But is that still enough today? What does it mean for WordPress to be secure? I think when people were giving that answer in the past, what they meant was that core WordPress doesn’t have a lot of known security bugs and that the security team quickly fixes vulnerabilities when they’re found. In that regards, WordPress core is doing very well. However, in terms of modern best practices, I started to think we could do more. 

When we think about security it’s always a balancing act.  There are two ends of the continuum.  On one end you have everything totally locked down where the site is immutable, you know, the most secure it can possibly be where nothing can be changed.  And on the other end of the continuum there is the approach of wanting to get work done, of wanting everything to be as convenient and as easy to access as possible.  You don’t want to have to continually jump through hoops in order to be productive.  Where you set that balance point is a judgement call.  It is the point where you say this is enough security, this is what is reasonable, while still allowing productive use.  It is the point where your site is reasonably secure and you’re able to get your work done. 

I realized that the common wisdom answer to the question is WordPress secure has been the same answer that’s been given for years,  I also realized that what is considered reasonable, good enough today, is pretty much the same as it was 12 years ago when I started using WordPress.  So I asked myself, in terms of security, what’s changed since then?  

What’s Changed in WordPress Security and What are the Best Security Practices?

WordPress Security Changes

In terms of WordPress core, I may be missing some things, but two changes come to mind:

1. First, around 2015 passwords were made more secure. The new password generating process in WordPress was improved. So out of the box, you have stronger passwords. 
2.  And second, around 2013 there was the introduction of automatic updates. I know that automatic updates are sometimes felt to be controversial or problematic because people are worried that their sites might break when there’s an update and they might not notice it immediately. They might not have a chance to test out the updates on a staging site or something. But on my sites, I have automatic updates enabled for minor WordPress version updates. And what that does is if there’s a security release in core then it’s going to be automatic applied.  I also use PatchStack as my security plugin.  It has an option to automatically update themes and plugins if they have a vulnerability and a new version is released. So I have that turned on also.  

Stronger password generation and automatic updates are two things added to WordPress to improve the stance towards security. 

Industry-Wide Security Changes

What about in the wider tech world?  Have their been significant changes and best practices in the industry?  What’s changed outside of WordPress? 

Two Factor Authentication

The number one thing that came to mind was two factor authentication. Two factor is everywhere now.  Pretty much every organization or platform that needs to secure anything now requires two factor authentication.  There was a big push for a 2FA option in core back in 2015 and there is a Github repo kept up to date for this purpose.  In other words, it is still kind of alive, but obviously it hasn’t happened.  It seems there are a few reasons why it hasn’t been included.  The biggest one is a worry about how to handle users who get locked out of their sites.  Not really discussed, but perhaps another deterrent might be that we want to make installing WordPress and getting up and running as easy as possible and this might be perceived as another barrier. However, today two factor is a best practice. By not having an option in core, or even a link to information about it, are we sending the message that it’s optional? What happens today is that we are sending new site owners on a quest to research and pick a solution.  

Privileged Access Re-authorization

The second big change I noticed in the overall tech world in terms of security is elevated privilege re-authentication. Linux, MacOS and Windows operating systems today all include some form of check or re-authentication when a user wants to execute a task that requires elevated privileges. Users are now familiar with the need to enter the admin’s password or to “sudo to admin status in order to complete certain tasks. Well, WordPress is the “operating system of the Web” and we could institute a similar procedure.  

According to security researchers session theft is on the rise.  When a hacker gets access to a WordPress session cookie they can use that to get site access without entering a password. Also, we’re all familiar with zero day plug in vulnerabilities. So account re-authorization would help address these types of issues.  This could be limited to a handful of tasks, such as those related to user privileges such as creating users, deleting users, changing user roles and permissions, as well as tasks related to plugin installation, removal, activation and deactivation. These would be good candidates for elevated privilege re-authorization. Requiring the admin to re-authorization in these cases like this would not be a huge inconvenience, but would be a good step to making our sites more secure. 

Encryption of Sensitive Data

A third area where there’s been a lot of progress generally in tech is the encryption of sensitive data that is stored in the database. We all remember in the past where large organizations would have their systems hacked and the hackers would make away with user passwords, Social Security numbers, maybe credit card numbers, or other sensitive information.  So the best practice today is that sensitive information needs to be encrypted. 

Well, not too long ago research by Snicco, a small WordPress security firm, brought to light the fact that there’s sensitive data stored unencrypted in the WordPress options table. This has included plugin license keys, account API keys for payment processors, as well as other sensitive data.  WordPress stores options in a key value format where we have an options name and a corresponding value. Providing a way to encrypt option values for sensitive data, like license keys or API keys would help to bring core in line with modern best practices. 

Secure By Default

It has also been recognized as a best practice that systems should be designed to be secure by default.  So another thing we can do to improve security is to remove or modify old rarely used features from core.  Yes, I’m thinking of XML RPC. Most WordPress professionals disable login via XML-RPC.   It doesn’t need to be in core anymore.  A plugin can be provided for the small number of plugins or services that use XML RPC. Along the same lines, by default the theme and plugin editors allow you to edit PHP on your site, and these are enabled by default.  Why not just turn that around and disable them by default? It’s another thing we can do to harden WordPress. 

Improved Session Security

This next item involves improving WordPress session security.  WordPress sessions are by default set to expire after 48 hours. Two whole days. That’s a long time to be logged into a website.  WordPress stores the session information in browser cookies. These are simple text files.  Thomas Raef, another security researcher, has reported that he’s seeing a large number of WordPress sites being hacked due to the theft of session cookies.  Apparently there’s a criminal marketplace system related to the theft and sale of session cookies. Hackers can steal session cookies through cross site scripting attacks and also get access to them if users have malware on their devices like your browser, your phone, your tablet or your computer.  With an unexpired session cookie a hacker can access sites without knowing the user password.

So I thought of a few things that perhaps could be done to harden session security: 

1. The most obvious one, of course, is to shorten the session timeout period.  Two days is a long time.  Core could make that change or security plugins could provide a user interface for changing the default timeout.  Would it really hurt to have a two, four, or six hour timeout?  Or even better, a mechanism where the timeout is based on inactivity. 
2. There could be an admin dashboard widget that shows the current user sessions and the last time the user logged on. We’re familiar with seeing something like that when we log into Gmail. 
3. When you log out of WordPress your user account could log the user out of all sessions. Typically, I think it just logs you out of that one user session. 
4. Another security researcher, Emil Trägårdh, mentioned to me that WordPress session cookies contain the IP address. However, WordPress allows sessions to continue, even when the IP address changes. For example, you can start a session in a coffee shop, then go to work and then go home. After all, you have two days and the session is still active, even though you’re connected to the Internet through all those different points and gotten a new IP address each time. So WordPress could lock the session to the IP address. 

After publication of this article, Calvin Alkan of Snicco Security mentioned to me that his Fortress security platform has a module for hardening session security.

Discussion and Conclusions

In looking at what has changed in overall security, what are best practices, I discussed several things:  Two-factor Authentication, Elevated Privilege Re-authorization, Encryption of Sensitive Data, Secure by Default, and Improving Session Security.  All of these mentioned steps involve repositioning the balance between security and access convenience.  They would involve extra steps to achieve better security.  It seems that they reflect generally accepted best practices.  The WordPress security posture hasn’t changed much over the last 10-12 years, but the overall industry’s set of best practices has.  If you agree then let’s raise our expectations both for WordPress core and for security plugins.  

Did I convince you that it is time and it would be advantageous to improve the default WordPress security posture? Or was it a matter of yes, I agree with some things, but not others? When you were the article, did you have your own idea brainstorm?  If you have some thoughts or suggestions that you want to share, feel free to leave them in the comments below or share them in the Dynamic WordPress Facebook group.  I hope you found the article interesting and thought-provoking.