Firming up WordPress’s security

There’re thousands of articles out there describing how to secure WordPress better against attacks, but I still had a little difficulty with the nuts and bolts, so I thought I’d detail the process I underwent here.

I recently had a bit of a security breach – some lowlife broke into my account and injected some phishing stuff into my personal webmail software. Consequently, I went on a bit of a security binge and deleted some apps I wasn’t using much, changed all of my passwords to ridiculously long strings, and set up layers of HTTP authentication on my WordPress login/admin pages, the latter of which is described here.

The general idea is to make it hard to get to the login/admin pages in the first place, which should block some attacks.

The [AskApache password protect](http://wordpress.org/extend/plugins/askapache-password-protect/) WordPress plugin will do all of this for you, unless it thinks your webserver doesn’t have the supporting software. It failed for me on Site5, saying I lacked HTTP digest authentication support, which is actually not true, as it’s enabled. I couldn’t be bothered debugging it though, so I proceeded with the manual route.

Create the password file

First, I created an htpasswd file, containing a login and password. There’re many sites describing how to do this, but on the terminal, it’s fairly easy:

htpasswd -c /path/to/.htpasswd myusername

Note that it’s a good idea to put the .htpasswd file somewhere outside the web root – your account’s home directory is one option.

Protect the login page

I opened up the .htaccess in the WordPress root folder, and added the following:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
<Files "wp-login.php">
    require valid-user
</Files>

Note that ‘ErrorDocument 401 default’ line – this is in place to avoid getting a ‘404’ error whenever you load up the login page. I’m not entirely sure of the details, but it seems that if the rewrite module is used (the thing that allows WordPress to define an arbitrary website structure, without needing physical files), then this causes problems with HTTP authentication.

Also, if you wish to protect access to the XMLRPC access point as well, you can add the following:

<Files "xmlrpc.php">
    require valid-user
</Files>

However, if you do this, I’m pretty sure pingbacks (the WordPress-specific version of trackbacks) will no longer work. I think trackbacks will still be functional – as far as I know, they use a different access point. If you use a desktop blogging app, you’ll want to make sure it can handle HTTP authentication. I know [ecto](http://illuminex.com/ecto/) can.

Protect the admin area

Finally, I created a new .htaccess file in the wp-admin directory, which looks like this:

ErrorDocument 401 default
 
AuthUserFile /path/to/.htpasswd
AuthName "Blog"
AuthType Basic
 
require valid-user