There’s a worldwide hacker attack going on against many WordPress websites.
The attack is a so-called “brute force attack” which aims to test different password and admin user id combinations to try and gain access to your WordPress administration dashboard.
Then the attack installs a bot which is then used to launch attacks on other servers or else perform other illicit activity.
How To Secure Your Website Against WordPress Brute Force Password Attacks
To help protect your site against this attack, you can add a secondary layer of administrator login security to WordPress sites.
To do this you basically create a .wpadmin file in the top home directory of your server system or in your server account home user area if you are on a shared server.
You then add a username and password pair, encrypt the password and then activate the security in the .htaccess file in your server space.
Here are the steps in detail:
(The following instructions are for server accounts that use cPanel, which is the most commonly used web-hosting account admin interface).
1. Create the .wpadmin file
Create a file with the name .wpadmin in your home directory. It’s important to name the file with the . (dot) before the file name, ie: .wpadmin.
eg. /home/username/.wpadmin
(“username” is your cPanel admin account username)
2. Create an encrypted password for a new user name/password combination.
The easiest way to do this is to use the htpassword generator at htaccesstools.
Go to www.htaccesstools.com/htpasswd-generator and enter the user name you wish to use and the password.
Note this combination should NOT be the same as the ones you currently use, neither for your cPanel login, nor for any of your WordPress sites. It should be a totally new user name and password combination.
Make sure you note down temporarily (and securely) or at least don’t forget what you have entered. You’ll need to know this in order to login each time later.
The password generator will then output an encrypted version of the password you entered for the user name that you entered. Copy and paste this into the .wpadmin file you have just created. That’s you need in the .wpadmin file.
Note that the .wpadmin file ONLY contains the user name (non-encrypted) and the encrypted version of your password. You do not add the non-encrypted version of the password.
Make sure you don’t forget the non-encrypted version of the password, else you won’t be able to log in!
For example:
user name: steve
non-encrypted password: abcdefg (by the way, a very poor password, so don’t ever use it. I’m just using it for the sake of this example)
The htpassword generator will create something like this:
steve:gjodWDQ8944qfr
The field after the colon, in this case: gjodWDQ8944qfr is the encrypted version of the password abcdefg.
You enter this line into the .wpadmin.php file. Then save and close the file.
3. Finally, update the .htaccess file
Cut and paste the following lines into your /home/username/.htaccess file.
:
ErrorDocument 401 “Unauthorized Access”
ErrorDocument 403 “Forbidden”
<FilesMatch “wp-login.php”>
AuthName “Authorized Only”
AuthType Basic
AuthUserFile /home/username/.wpadmin
require valid-user
Make sure you substitute your own username int the line AuthUserFile /home/username/.wpadmin.
Your secondary login wall of defence is now complete.
From now on, when you want to access a WordPress Admin dashboard on your web server, it will first prompt you for the username and the (non-encrypted) password combination that you configured as above.
For example, in this case, that will be:
login: steve
password: abcdefg
It will then let you pass and direct you to the normal standard admin login for the WordPress site you requested. You then log yourself in on the WordPress dashboard as normal.
Note that if you have WordPress pages that are password-secured using the standard WordPress password protect functionality, then the above procedure will require you to perform the double login using your secondary username/password for these pages as well.
This may be a feature you are happy to live with – or it might be an irritation and complication that you’d rather not have.
In this case, you’ll have to weigh up the pros and cons of implementing this additional security versus the extra login overhead involved.