This feature uses .htaccess files which are only compatible with Apache, Litespeed and a very few other web servers. Some servers (such as NginX and IIS) are incompatible with .htaccess files. If we detect a known to be incompatible server type this feature will not be shown at all in Admin Tools' interface. It should be noted that even if you do see it in the interface it doesn't necessarily means that it will work on your server. This depends on your server's capabilities. If you are unsure or believe it doesn't work please consult your host.
administrator directory of your site. It does so by
using Apache .htaccess and .htpasswd files, so it won't work on hosting
which uses IIS or NginX.
Some prepackaged server bundles and some live hosts do not allow
using .htaccess files to password-protect a directory. If it is a
local server, edit your
If you are on a live host, please consult your host about the possibility of them allowing you to use this feature on your site.
There are several password hashing schemes supported by
different versions of Apache. It's possible that if you password
protect your administrator directory on one server and then transfer
your site on a different server you will receive a blank page or an
Internal Server 500 error page when accessing your site's
administrator backend. This is normal and expected. All you have to do
is to remove the
To apply the password protection, enter a desired username and password and click on thebutton. After a few seconds your browser will ask you to supply the username and password you just specified. This will also happen each and every time anybody tries to access the administrator back-end of your site. In other words, you have to share the username and password with all back-end users of your site.
If you wish to remove the password protection you can either
remove both the
.htpasswd files from your administrator directory,
or click on the
There are two more options on this page you should be aware of.
Administrator resources to protect. In the past, the administrator password protection was an all-or-nothing feature. This is no longer the case. This option lets you choose which resources under the administrator directory will be protected with a password. “Joomla” only protects Joomla's index.php (the administrator application entry point). Everything else can be accessed freely, including .php files from third party applications. “All PHP files” protects all PHP files in the administrator folder and its subdirectories. “Everything” works the same as old versions of Admin Tools, disallowing access to any file in the administrator folder and its subdirectories, regardless of its extension.
We recommend using “Everything”. That's the default option and equivalent to how things worked in the past.
In very rare cases, typically third party payment plugins for e-commerce applications, you may need to allow access to arbitrarily named .php files hosted in a directory under your site's administrator folder. This is NOT recommended; using Joomla's com_ajax is the best way for developers to do that. If, however, you do bump into this case you can select the “Joomla” option. This is the least secure option and you may also need to add an exception in the .htaccess Maker page if you are using that feature as well.
Reset custom error pages. This will resets Apache custom error pages for HTTP 401 and 403 to the most minimal built-in error page in Apache. This prevents a 404 Article Not Found error when trying to access the administrator login page after enabling the Administrator Password Protection feature. You are strongly advised to keep this option enabled unless it causes and HTTP 500 Internal Server Error problem.
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 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.
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
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
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.
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:
Password-protect Administrator as your first line of defence. This will reject the vast majority of attacks. Only attackers who have successfully guessed, or coerced a legitimate user to divulge, the username and password used for this feature will make it through to the next layer of your defences.
Administrator Secret URL Parameter in Admin Tools' Web Application Firewall configuration as the second line of defence. An attacker would likewise need to successfully guess, or coerce a legitimate user to divulge, the secret URL parameter to get to the login page of your site.
Strong passwords which are not already known to attackers. This can be implemented by combining two features, a core Joomla feature and a feature in Admin Tools itself:
Go to Users, Manage, Options on your site and change the settings in the Password Options tab to require a minimum password length above 12 characters, with a minimum of at least 1 number, symbol, uppercase, and lowercase letters. This means that your users will need to set up a relatively secure password — but do keep in mind that it doesn't affect existing users who have already set their passwords!
Go to Components, Admin Tools, Web Application Firewall, Configure WAF, and enable the the Warn about use of well-known passwords feature. When a user sets a new password, it will be securely checked against the Have I Been Pwned service to make sure that the password is not known to attackers.
Ask the users to use a password manager, their browser, or at least a random password generator service, to create secure passwords.
Ask the users to use a password manager. Even their browser's password manager is better than them trying to remember a password.
As a last line of defence, force the users to use Multi-factor Authentication. Go to Users, Manage, Options on your site and change the settings in the Multi-factor Authentication page. In the Enforce Multi-factor Authentication option select all the user groups with backend access to your site. Next time a backend user logs into your site they will have to set up Multi-factor Authentication to proceed. Even if an attacker has guessed or coerced the administrator password protection credentials, the administrator secret URL parameter, and the user's username and password they will still be unable to log into the site thanks to the Multi-factor Authentication protection.
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.
 Joomla 3.0 to 4.1 inclusive had Two Factor Authentication which, when enabled, required the user to enter a secret code along with their username and password to log into the site. Joomla 4.2 and later has Multi-factor Authentication which, when enabled, shows a captive page after initial login. The captive page asks the user to provide a secondary authentication such as a code generated by an authenticator application on their phone, using a Yubikey, or using using WebAuthn on their device.
Both of these Joomla features were contributed by us to the Joomla project. The old Two Factor Authentication was a feature in Admin Tools 2.x, whereas the Multi-factor Authentication used to be the Akeeba LoginGuard extension we developed between September 2016 and May 2022 (when we donated the code to the Joomla project).