TL;DR: It protects your site against stolen administrator user credentials, automated programmes trying to brute force your administrator username and/or password, as well as the secondary effects of degraded site performance or outright denial of service (DoS) which might be caused by that activity.

By default, Joomla allows anyone to view the administrator area login page by visiting the /administrator URL of your site. This may be problematic for two reasons.

For starters, an attacker may steal the login credentials (username and password) of a user with privileged, backend access to your site, such as a Super User. This can happen in many ways, typically through social engineering methods. If the user does not have Two Factor Authentication or Multi-Factor Authentication^[1] enabled on their user account the attacker has gained access to your site. While you can, and should, require Multi-factor Authentication for all users with backend access to your site most people don't know they can or should do it. Hence the need for an easier secondary authentication barrier.

Further to that, attackers tend to use automated software (bots) which attempt a large number of username and password combinations, hoping that they will guess the correct username and password combination to get into your site. This is called a “brute force” attack.

Secondary effects of brute force attacks

Brute force attacks, even when they ultimately fail to discover a usable username and password combination, can have secondary effects on your site which might be even worse than the intended purpose of the attack.

As noted by the name, a brute force attack is crude, inelegant, and forceful. It is essentially one or more computers sending a large number of of POST requests to your site's /administrator/index.php file in a fairly short period of time to simulate the submission of the login form and observe what happens. Depending on the experience and the intelligence of the attacker this may be a dozen requests per minute, to several dozen requests per second.

Normally, these requests need to be handled by Joomla. This means that the request is received by the server's network stack which sends it to your web server (Apache). Apache will look at your .htaccess files to determine if the request should be blocked. If not, it asks PHP to handle the request. Usually this means that PHP will check if there is a free spot in the FastCGI Process Manager pool, spin up a new PHP process, load up Joomla, which loads all of its system and actionlog plugins, runs a lot of set up code, talks to the database and so on and so forth until it comes back with a reply that is several dozens of Kilobytes long. This reply is sent back to Apache, which sends it to the server's network stack, which sends it back over the Internet to the bot that made the request. That's the simplified version of what is going on. This takes several hundreds to thousands of milliseconds.

If a bot operated by an inexperienced, or at least not very perceptive, attacker sends dozens of requests per second it's possible to get over the server's capacity to handle requests. Your site starts becoming sluggish and may even stop responding altogether if the server gets overwhelmed. This means that the brute force attack unintentionally escalated to a service degradation or even a Denial of Service (DoS) attack — the latter more likely on cheaper, shared hosting.

Please keep in mind that this unintentional escalation to service degradation / DoS is an inherent side-effect of how requests are handled by the web server. This will happen regardless of whether Joomla has any security plugin installed. In fact, any security plugin will add more processing time to each request, further compounding the problem. Even worse, the more intricate the brute force protection it offers the more likely the unintentional escalation to service degradation / DoS becomes! That is to say, showing a secondary login page handled by the security plugin will make the unintentional escalation to service degradation / DoS almost a certainty, whereas something less intrusive like the Administrator Secret URL Parameter feature in Admin Tools makes that less likely.

Of course, the best way to avoid this problem altogether is to have the web server itself block the request, without having PHP handle it. Indeed, this is what the Administrator Password Protection feature does! When a request is received the operating system's network stack receives it and sends it to your web server (Apache). Apache will look at your .htaccess files and determine that it should expect an HTTP Authorization header with a specific username and password to be present. If this is not present, Apache responds with an HTTP 401 Authorization Required response within a few nanoseconds (fractions of a millisecond), the response being typically just a few dozen bytes. Since the bot requests are rejected thousands of times faster than if they went through PHP and Joomla, the server's capacity for responding to these requests is likewise several thousand times bigger which makes it extremely unlikely (and practically impossible) that your server will experience degraded performance or a denial of service while a brute force attack is in progress.

Therefore, the very simplistic Administrator Password Protection, which is implemented at the web server level, is far better at protecting your site against a brute force attack than anything else which can be implemented in PHP code.

Practical steps to securing your site's backend access

As the failure of the Maginot Line in the beginning of WWII taught us, it's not prudent having a single layer of defence, no matter how good it's perceived to be. The best defence is layered. With that in mind, we very strongly recommend the following setup:

As a side note, please keep in mind that your username and your email address should NOT be treated as a secret for the purpose of login security. Always assume that your username and email address are known to the attacker, or easy to find out.