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 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 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
Add us on Facebook!
Easy inclusion of OpenSSL into iOS projects
Oddly, iOS doesn’t provide any OpenSSL implementation at all — If you want to do anything with crypto (like checking signatures, checksumming, etc.), you have to build in the library yourself.
I came across a great XCode project wrapper for OpenSSL yesterday, by Stephen Lombardo. This is an XCode project file that contains a target to build OpenSSL from source, and works with both Mac and iOS projects. I made some modifications to it, in order to make it work by just dropping in the OpenSSL source tarball, without having to dirty up your source tree with the extracted OpenSSL distribution.
Here’s how to use it:
Library/opensslwithin my project tree).On the Build tab for your project’s target, find the “Header Search Paths” option, and add the path:
(Assuming you’ve put openssl.xcodeproj at the path
Library/openssl— adjust as necessary).Then, you can just import and use as normal (
#import <openssl/dsa.h>, etc).Download it here