WordPress is a great tool for website developers. As of today, it powers over a quarter of the Internet, so clearly the team at WordPress is doing a few things right! With all the great features and support that WordPress provides, there are a couple problems that make secure user authentication in WordPress a challenge. When I began building Stormpath’s WordPress plugin I knew I’d have to meet this challenge head-on.

WordPress has been a go-to tool since the release of 1.2 in 2004. I’m even the co-host of my local WordPress Meetup chapter and co-organizer of our annual WordCamp. The WordPress community is a welcoming group of developers that I’ve been proud to be a part of. And WordPress itself provides both an easy solution for anyone from the individual blogger to the start-up or small business with simple site requirements, all the way to enterprise solutions for complex website management.

So, how does WordPress make authentication hard? Simple: Old hashing, and problematic database coupling. The use of cookies in WordPress authentication is ok, but there is room for improvement. Let’s look at the impact of these elements more deeply.

WordPress Uses Old Hashing

The big glaring red flag of user authentication no-no’s, WordPress is using outdated hashing technologies. Over the last few months, I’ve spent more time looking at the code that deals with the authentication system than I thought I ever would. It’s a mess!! If you were to dig into the mechanics behind the native WordPress authentication, you would see that WordPress is using a tool called phpass, which is a portable hashing password library.

Phpass provides password hashing with bcrypt set as the preferred algorithm. Using bcrypt is the industry standard and should be used the majority of the time. I do however, have a little bit of an issue with the library itself because it still supports PHP 3+. Sure, it may just be a side effect of a well-written tool, but I find that it gives devs an excuse to continue using older, no-longer-supported and thus inherently less secure versions of PHP.

The issue with the WordPress implantation of phpass is that they are still using MD5 hashing for their passwords.

If you look at the actual code here, it is prefaced with a comment stating that they are locked into using MD5 since “it’s the only cryptographic primitive available in all versions of PHP currently in use.”

I understand the WordPress team’s desire to support the broadest swath of their customer base possible, by continuing to support older versions of their CMS, but there are ways around this specific issue. In the Stormpath WordPress plugin I solved it like this:

Now your site is able to use a more secure version of password hashing (PASSWORD_DEFAULT is set to bcrypt currently but will maintain the most standard version as new ones come into play).

This problem has plagued WordPress since the beginning and because they want to keep backward compatibility, they keep using insecure hashing of your passwords. (Resist! Try Stormpath!)

WordPress Tightly Couples Users to Database

In the development of the Stormpath WordPress plugin, I found that it was difficult to keep all of the user information outside of the WordPress database. One of the biggest features of Stormpath is that we store your users in our datastore so you don’t have to take on the burden of securing that data. The core of our business is to offer you world-class security so that you can focus on building the parts of your site or application that are core to your business.

So what’s the problem here? It’s simple. The way WordPress tightly couples the authenticated user in their own database makes it hard for us to completely ignore the wp_users table since your users will be stored inside of Stormpath.

When a user logs into an application that utilizes Stormpath for authentication, that user is provided with an access token that can be used for all future requests. With native WordPress auth, when we log a user in, we have to “hijack” that login request with the hooks provided and log the user in against the Stormpath directory.

This authentication attempt gives us an access token, however, because of the coupled accounts in WordPress, we need to also log in the WordPress user, giving us access to all of their previous posts and data.

Once we log the WordPress user in, we set all of the Stormpath access token cookies, and then set the current WordPress user based on the account we found with the same email address inside of WordPress.

It would be difficult inside of WordPress to de-couple the users object to allow for a replacement user management system. It’s possible though by writing to an interface. I am not sure why an interface was not written for the authentication portion since interfaces are used in other parts of the code. Had they done this, changing out the implementation of user authentication would be a much simpler matter.

WordPress Uses Cookies

We’ve talked a lot on our blog about where to store authentication tokens. The big debate of sessions vs cookies is an ongoing one. Here at Stormpath, we suggest you store them in cookies. The good news about WordPress authentication is that they’re using cookies to store your authentication token!

WordPress Cookies

You’ll notice in the cookie entry that they are forcing the cookie to only be used from a browser, preventing access from a script. The issue though, is the lack of enforcement of making the cookie only available on secure. The site this screenshot is from is served only over HTTPS, so there is no reason WordPress can’t force the cookie to be secure only. The cookie expire time is set by hooking into a filter auth_cookie_expiration and returning the number of seconds you want the cookie to be valid for.

What User Authentication with Stormpath Can Do for Your WordPress Site

The Stormpath WordPress plugin offers more security for your WordPress users. Even though we still use the WordPress user object from the database, we prevent access to that user directly and require you to authenticate with the user stored inside of the Stormpath datastore. We have made it look and act exactly as it does with the WordPress authentication system so your end users are unaware of a change happening.

We continue to improve reliability and compatibility with other plugins as well as provide you some features that the default installation of WordPress does not.
Ready to dive in? Grab the Stormpath WordPress Plugin from the WordPress Plugin Repo! And as always, if you have any comments or questions, hit me up below, or on Twitter @bretterer.

// Brian
?>