WordPress : Password protect wp-admin directory and wp-login.php
Hardening WordPress by adding both wp-login.php AND wp-admin password protection is a great way to protect your website from hackers.
But isn’t it safe enough if I use a strong password on the standard wp-admin login? Well, yes, from a brute force attempt, but single factor authentication (simple username and password) means that there’s only one layer of security between you and the bad guys. Lets suppose you had to reset your WordPress password, and got it emailed to you. How secure is your email? Were you in a public wifi hotspot when you picked up that email? It’s not just about how strong your password is.
We’re going to add another layer, using the web server’s own htpasswd technology. This technique can be applied to Joomla, Drupal and many other Content Management Systems with a few minor tweaks.
Why htpasswd is better than another PHP driven single factor authentication layer
While it is not the most graceful of solutions, Apache’s (assuming your webserver runs on Apache – most still do) htpasswd basic authentication system offers two great advantage over most WordPress security plugins.
- The user is challenged before the request for the page is served. This means that no PHP is processed until the user authenticates. That that means that no MySQL database query is processed either. When your website is under a brute force attack, all of the requests are stopped by apache. This saves a lot of CPU cycles when your site is under attack.
- Authentication failures get logged to the apache error_log file (/var/log/httpd-error.log or for cPanel servers /usr/local/apache/logs/error_log). Therefore if you have a login failure tracker such as LFD (which comes with CSF from configserver.com) or BFD (which comes with APF from www.rfxn.com) then the attacker will only get a handful of bites at the cherry before they get banned by the firewall. A network level ban is far better than one engineered by the application level.
Why the wp-admin directory AND wp-login.php should be protected
Many guides only suggest you protect the wp-admin folder only, but that’s shortsighted. Why? because it won’t prevent brute force attacks reaching wp-login.php which is in the top directory of your WordPress installation, eating up your bandwidth/CPU and possibly exposing your login details. So, this guide locks down both areas.
Step 1 – Protecting wp-admin using cPanel’s Password Protect Directories feature
If you don’t have cPanel, don’t panic, just click on the guide below to creat your passwd file and protect your wp-admin directory manually:
In cPanel, click on the Password Protected Directories icon in the Security section.
Then find the wp-admin directory. Navigate through your directories by double clicking the directory names. When you find the wp-admin folder, click on the little folder icon.
Creating the user’s password hash
The screen has two areas, so we will start at the bottom, as it makes sense to create the user before we restrict access. Just enter the username you wish to use, and the password (a nice strong on of course) and click the Add/modify authorized user button.
You will see a confirmation message, just accept it and you will be returned to the same screen again – your new user should now appear in the Authorized Users list at the bottom. At the top of the screen, we just just need to activate the protection. Tick the check box, and enter a nice stern warning in the Name the protected directory: box as shown and click Save.
Step 2 – Protecting wp-login.php
Currently (11.40) cPanel doesn’t provide a graphical interface for protecting individual files, so this always has to be done manually.
In the root directory of your WordPress installation, create or open the .htaccess file. At the top of it, add the following:
Note: If you protected wp-admin manually in Step 1, then change the AuthUserFile path to the passwd file you created yourself. If you used cPanel, then the path to the file will be along the lines of:
That’s it! You have now protected both wp-admin and wp-login.php – but wait! There’s more
Step 3 – Preventing 404 Not Found and Ajax errors
Two things can go wrong when you implement this, and here’s how to fix them:
404 Too many redirects error loop
HTTP Basic Auth first sends a 401 Unauthorized with it’s request for a password from the browser. The webserver tries to serve the corresponding error file usually 401.shtml. Because it can’t find it (because who creates those anyway!) it then creates a 404 error and tries to serve the 404.shtml, which it also can’t find… which creates a 404 error and tries to serve the 404.shtml, which it also can’t find… deja vu?
The simple fix is to add this to the top level .htaccess file – immediately below the </FilesMatch> statement is safest:
If that doesn’t work, create an empty file in your website’s root folder called 401.shtml and add this to your .htaccess file: