Prevent attacks on the wp-login.php

Currently I'm testing several security plugins for WordPress (look forward to the upcoming articles about it) and one of them drew my attention to a security hole. So I had you recommended some time ago the complete order "wp-admin" with the help of a .htpasswd file. This makes sense, because if you don't offer registration and login for your users, or like me simply use an external comment system like Disqus, you can stop all the fake registrations, brute force login attempts and other hacks to the admin area of WordPress. Locking the folder "wp-admin" so it makes perfect sense.

Too bad that some plugins want access to the folder and that this folder is automatically made available to "wp-login.php" redirected. This is exactly what this is about, because one of the security plugins just mentioned drew my attention to the fact that the "wp-login.php" is still under heavy attack. No wonder, because the file is not even in the locked folder "wp-admin". So whether you have blocked it or not, as long as your users are not allowed to register and log in, you should check the "wp-login.php" also secure it with a .htpasswd file to avoid attacks on the file and thus indirectly improve performance again.

You can find out how to do this here.

protect Wp-login.php with .htpasswd

1 First you have to create an empty file named .htpasswd. Do not forget the dot at the beginning and create the file with an editor, not with Word or other writing programs.

2. next, you create with the Htpasswd generator a user name and a password. Remember them well and copy the created content into the .htpasswd file you just created. Save it and you are done with step two.

3. copy the saved .htpasswd via FTP into the main directory on your server or webspace.

4. you have to copy the following code into your existing .htaccess file. How a perfect .htaccess should look like, you can find out here.

AuthType Basic
AuthName "My Protected Area"
AuthUserFile PATH TO ->/.htpasswd
Require valid-user

5. now it is getting a little tricky for many people. You have to change the code above so that the complete path of your server is given. Just change the "PATH TO ->/.htpasswd" with the path to your .htaccess. How exactly do you figure out the path, is described here very nicely.

Performance and security through login protection

This completes the last step, and thanks to the additional password request via .htpasswd, the constant hacking attempts on this file also end. WordPress has been struggling with such automatic attacks for a long time and the recurring accesses logically cause a lot of load on your server. But once the file is protected with a .htpasswd, attackers have no chance at all and are simply blocked completely before they can start any hacking attempts or brute force logins. They won't even be able to get around the password, as long as you have created a long and complex password. I hope this tip could help some of you. For anyone who has disabled user registration on his website, this method is an absolute must.

This might interest you too:

About Christian

My name is Christian and I am co-founder of the platform fastWP. Here in the magazine I am responsible for the more "technical" topics but I like to write about SEO, which has been my passion for over 10 years now.

3 thoughts on “wp-login.php mit .htpasswd schützen”

  1. Hello, Christian,

    you have a tip for those who have activated a customer login. Among other things I have activated a customer account with Woocommerce. I don't land in the backend with these access data when I try to log in via wp-admin. At least that's a good thing. But if I want to log off from the customer account the htaccess protection intervenes. But if I open an account and login the protection does not work. So I don't understand why it only intervenes when I log out. But have you ever thought about that? Or an alternative protection if you want to access the domain/wp-admin page?

    1. Hi Martina, I'm afraid I can't really say anything qualitative without dealing with your case in more detail here - and that goes (hopefully understandably) beyond our comment support. Since this is unfortunately more often the case, I had a very nice idea how we can tackle this more common problem 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *