Secure WordPress login

Secure WordPress login

WordPress is without question the most used content management system. Due to its widespread use, WordPress installations are also popular targets for attacks. That’s why today we want to show you two methods how to protect the WordPress login form against such attacks.

  1. background and goals
  2. Tip 1: Hide login
    1. Changing the default path
    2. Taking visitor statistics into account
    3. a notice
  3. Tip 2: Additional password protection
  4. Additional tip: ErrorDocument
  5. Conclusion

In the case of an attack, one must distinguish whether it is a automated attack attempt on random WordPress installs or around a targeted attack acts on your own side (e.g. through a competitor). Fortunately, the second case is rare, and automated brute-force attacks often follow a similar pattern. Trying out login information is a popular strategy for gaining access to WordPress and using it for your own purposes.

Because these attacks are not targeted, anyone can be affected. This even includes websites that are not even powered by WordPress. I’ve seen access logs from Joomla! or TYPO3 page views `wp-login.php`, the WordPress login form. So please don’t think “My little site… who would want to hack it?”, but take security seriously.

But how to protect the form from such arbitrary calls? The protection should pursue two goals at the same time:

  1. Securing the form
  2. Taking visitor statistics into account

But before we take a closer look at these two methods for additional login security, here are the strongest and most important method, which cannot be replaced by anything: secure passwords! Choose a secure password for your WordPress user. If you take this to heart and keep your system up to date (keyword install updates!), this is already sufficient for 80% of WordPress sites.

By default, the backend of WordPress is via “/wp-admin” respectively. “wp-login.php” accessible. Of course, all attackers know that too. Therefore, changing this standard can be a strategy in order to be able to ward off at least many general attack attempts.

Changing the default path

Change the login URL “/wp-admin” or “/wp-login.php”, many of the simple attacks are repelled directly. If the login has been changed, the simple, automated attackers no longer assume that it is WordPress and usually give up.

The login path is changed using a plugin, such as WPS Hide Login. There are other plugins, but some of them are outdated.

Taking visitor statistics into account

About the plugin “WPS Hide Login” although the call from “/wp-admin” prevented, but if this call is forwarded to the actual website, it still counts for the visitor statistics. So that the unwanted calls to the now hidden login do not count as visitors, they can be answered with an error status code.

The simplest way is to define it with a `.htaccess` file. To do this, create a folder (e.g. `error`) in your WordPress directory (below /html/wordpress/) and create the file `.htaccess` (pay attention to the dot at the beginning) with the following content:

RewriteEngine On
Options +FollowSymLinks
RewriteEngine on
RewriteRule .* - [R=404,NC,L]

As a response code I have `404` chosen what for NOT FOUND (Content not found). Carry now as “Redirect url” in the plugin settings “WPS Hide Login” (Settings → General → WPS Hide Login) “error” (or whatever your created folder is called). So now all calls from “yourdomain.de/wp-admin” redirected to the folder and acknowledged with the specified status code. The visitor is no longer counted. However, this option is not available for the “Easy Hide Login” plugin.

Hiding the login is very easy to implement and convenient to use, but it is not a real security measure, it is just that: hiding the login. The somewhat misleading technical term is “Security by obscurity”. If the form is found anyway – and your admin password is short or easy to guess – all doors are still open to an attacker. So again: Use secure passwords!

A short analogy from the real world: If you hide your front door key under the doormat, everyone who knows the hiding place can still get in – and let’s be honest: The hiding place is easy to guess 🙂 It would be better to have a box with it a combination lock, so another security factor. We’ll get to that now…

Tip 2: Additional password protection

Multi-Factor Authentication is the gold standard for logins. For example, when logging in to the bank, a TAN is required to confirm certain actions. You can also activate such a two-factor authentication with WordPress using the Two-Factor plugin.

Another way to keep unwanted visitors from logging in with a second factor is to set one up additional server-side password protection. Before the login request reaches the WordPress installation, it is processed by the web server. An additional “bouncer” can already be installed at this level.

You can either do this in the customer center via the Function Tools → Directory Protection set. You can find detailed instructions on how to do this in the Directory Protection FAQ.

Alternatively, you can also create a `.htaccess` file manually for this purpose. This time in the directory `html/wordpress/wp-admin` and with the following content:

AuthType Basic
AuthName "Passwortgeschützter Bereich"
AuthUserFile /home/www/p123456/html/wordpress/wp-admin/.htpasswd
require valid-user

into the file `.htpasswd`which is placed in the same directory, you then write the User password hash combinations. You can create this file with the .htpasswd generator, for example. It could then look like this:

Lukas:$1$rapNxkdm$wJf8sp5Obk2IItayLC35e.

Here is not the password in plain text, but a hash of the password. The login takes place later, of course, with the original password.

If you have done everything correctly, when you call `/wp-admin`, the first thing you see is a login window displayed directly by the browser, where you log in with the information from the `.htpasswd`. Only after this hurdle is the actual login form delivered by WordPress. If a caller cannot authenticate himself to the server, he receives the status code 401 Unauthorized and is therefore not counted in the visitor statistics.

Additional tip: ErrorDocument

By specifying an `ErrorDocument` you can prevent accidental visitors nicer error message Show. Since automated bots often do not evaluate this – especially not your individually designed message – you can also reveal who to contact if you have problems logging in, or reveal the path to which the login was moved.

The two methods presented achieve something similar in different ways: The WordPress login form can no longer be called in many simple attacks. This can increase the security of the website. If you want to delve deeper into the topic, you can find more information in the blog article “WordPress – but safe!”.

WordPress Login Previous post WordPress Login: Login to WordPress (URL)
informationen Next post WordPress Login & Common Problems » fastWP