So how scummy are spammers? What kind of low rent individual decides to devote their life to the pursuit of spamming websites? Yesterday, like countless days before it, some scum sucking individual decided to point a botnet at one of our sites and effectively tried to hammer it open with an absolute flood of traffic, trying every username and password combination it could conjure in an attempt to crack open the WordPress login. Little did the spammer know, we keep our properties locked down like Fort Knox. Brute force attack or no, you’re not getting in. Of course, that doesn’t stop them from trying and try they did.

In fact, they tried so hard that they brought down our webserver for the better part of the day. After thorough investigation, we discovered the cause of the tidal wave of illicit traffic and promptly shut the source down. We had all sorts of handy WordPress plugins installed to protect the websites, but we didn’t count on the bots’ failed login attempts sucking up all the server’s processing power to the point where no one else could get to the site. Maybe its just me, but if you are going to try to jackhammer the login for the site, wouldn’t it make sense not to hit it to the point where the page doesn’t even load? I know that pesky logic. It always gets in the way.

So once we’d stabilized the servers after our day of failed productivity, I went out in search of a solution. That is when I stumbled upon protecting your WordPress login page (wp-login.php) on Apache with a combination of the .htaccess and .htpasswd files.

This doesn’t technically stop a brute force attack (truthfully nothing does), but it does block it from sponging up your server’s resources like all those php processes checking user logins against the mySQL database. Basically, it lays an additional layer of authentication on top of your wp-login.php page. The server triggers a popup where you are forced to enter the credentials you’ve defined in your .htpasswd file and if its successful, it passes you through to the WordPress login page. If you have a dual login setup, its probably a safe assumption that your login is probably not user & 1234. There are easier targets for spammers to take advantage of so most likely they will hit this wall and promptly move on to fresh meat. Regardless, they can slam that top-level authentication will little impact on your server resources.

So how do we set this up. Very easily in fact. You just need access to your file structure via FTP or your web host’s management console. You can use this handy resource to create/encrypt the .htpasswd file. Simply save out the results and upload it to the root of your web directory.

The only real tricky part is identifying the path on your web server to the .htpasswd file you just loaded up. If you don’t know it, you can use this tool to identify it with a few lines of php code or simply ask the support staff at your webhost. Here is what the finished block looks like:

AuthType Basic
AuthName "User name and Password are required for entry:"
AuthUserFile /PathOnWebServer/WhereFileIsLocated/.htpasswd
<Files "wp-login.php">
  Require valid-user

Pay special attention to those last three lines. I’ve seen several examples online that omit the File tags. When you do that, it basically forces any page hit across your site to be authenticated. Your readers aren’t going to like that too much. This directive isolates the authentication to only apply to the wp-login.php file. Once you have that code, append it to the text of your current .htaccess file and upload it up to the server. Since that .htaccess file is extremely sensitive and can take down your entire website, I always — always — always recommend making a copy of it and saving it out to your computer before you ever make any changes to the original file. Its one of those best practices that will save your ass one day.

So there you have it. Feel free to setup your welcome mat on your new HTTP AUTH login for any spammer that wants to try to wrench open your WordPress login. They are certainly welcome to try, but if you have two strong passwords, its not happening. Now you also have the peace of mind that these worthless individuals aren’t sucking up your server resources in the process.

http_auth