Support

Documentation

This documentation page is for Joomla! 3.x

This documentation page does not apply to our software versions for Joomla! 4.0 and later versions. If you are not using Joomla 3 please consult the documentation index to find and read the correct version of the documentation.

Protect your administrator back-end with a password

[Important]Important

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.

The Password-protect Administrator tool of Admin Tools is designed to add an extra level of protection to your site's administrator back-end, asking for a username and password before accessing the administrator login page or any other file inside the administrator directory of your site. It does so by using Apache .htaccess and .htpasswd files, so it won't work on IIS hosts.

There are multiple reasons to implement this protection:

  • Prevent fingerprinting. Malicious users tend to scan the publicly available, static files a site before attacking it to find out if it has an old, vulnerable version of Joomla or one of its extensions installed. This is called "fingerprinting". Part of the fingerprinting is accessing translation INI files and static CSS, JS and image files in the administrator folder. Applying password protection will make fingerprinting less reliable for the attackers which makes it less likely they will attempt to attack your site at all.

    On the flip side, if you have software which incorrectly stores static files (CSS, JS, images, ...) in the administrator folder and expects them to be accessible on the front-end of the site this will "break" your site, in the sense that some or all of your frontend pages will be asking your site visitors for a username and a password. If this happens you can choose the "All PHP Files" or "Joomla" options under Administrator resources to protect. In this case, though, your site will not be protected against fingerprinting. It's best to ask the developer of the offending extension to move the common static files into Joomla's media folder which has been available since 2007. Then you can upgrade your Administrator resources to protect option to Everything to get the best protection on your site.

  • Direct access to vulnerable files. Your extensions' backend files, including .php files, are stored in the administrator folder. While it's customary for .php files to have a protection against direct web access it's possible that someone forgot about that or deliberately expects these files to be web accessible for site administrators. A malicious user can directly access these files. If these files have a security vulnerability it's possible for the malicious user to perform unintended operations ("hack") your site. Using a password protection on the administrator directory with the Administrator resources to protect option set to Everything all All PHP Files will mitigate this problem.

    On the flip side, some third party extensions place .php files in the administrator folder and expect them to be publicly accessible. The most common use case is e-commerce extensions putting payment callback scripts in the administrator directory. In this case you'd need to set the Administrator resources to protect option to Joomla. However, in this case your site would not be protected against neither fingerprinting nor direct access to vulnerable files. The correct approach is to use a custom component controller; or com_ajax together with a plugin, module or template. The former option is available since Joomla 1.0 released in 2005. The latter option is available since 2013. Even in cases where a remote service cannot use a URL with query string parameters (therefore requires a directly accessible .php file) it's perfectly possible to either create a redirect in the .htaccess, NginX configuration or web.config file; or create a directly accessible .php file which operates as a "shim" for calling com_ajax. Please ask the developer of the offending extension to use one of these solutions. Then you can upgrade your Administrator resources to protect option to Everything to get the best protection on your site.

  • Brute force Joomla administrator login. A lot of malicious users employ automated software ("bots") to try several different combinations of common usernames and passwords against your administrator login page. On most sites this would succeed, allowing the attacker to log into your site and wreak havoc. Using the administrator password protection is one of the protection layers you can apply to your site to mitigate this kind of attacks. The attacker would first need to figure out this common username and password before attempting to brute force your Joomla login. Moreover, the password protection is super fast; practically speaking, this allows your server to reject the requests from the attacker's bots without consuming too many resources and without running the risk of slowing down your site or rendering it inaccessible. You should also at the very least use long, complex password (ideally: randomly generated passwords with at least 32 lowercase and uppercase letters, numbers and symbols) stored in a password manager; a password you can easily remember is NOT a secure password! Moreover, you should also be using Two Factor Authentication (built into Joomla) or Two Step Verification (available free of charge with Akeeba LoginGuard). If you have Joomla 4, you should also look into enabling Web Authentication if your device permits it for easier and more secure logins. Finally, you should DISABLE Joomla's "shared sessions" feature since it allows someone to log into the frontend of the site and immediately gain access to the backend of the site as well. This is a security nightmare, mitigated by the administrator password protection.

[Important]Important

Some prepackaged server bundles, such as Zend Server CE, and some live hosts do not allow using .htaccess files to password-protect a directory. If it is a local server, edit your httpd.conf file (for Zend Server CE this is located in C:\Program Files\Zend\Apache2\conf or C:\Program Files (x86)\Zend\Apache2\conf) and modify all AllowOverride lines to read:

AllowOverride All

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.

Password-protect Administrator

The Administrator resources to protect option controls what will be locked behind a password:

  • Everything. All files and folders (including those in subdirectories) of the administrator folder of your site will be password-protected. Please note that this is the only option which password-protects access to static resources such as CSS, JS and image files.

  • All PHP files. Only the access to .php files will be password protected as long as these files are placed in the administrator folder of your site or inside any of its subdirectories, no matter how many folders deep. This options DOES NOT protect static resources such as CSS, JS and images files with a password.

  • Joomla. Only access to Joomla's administrator application will be protected with a password. This is the weakest form of protection. We do not recommend this unless you have a specific reason to do so and you're also using the .htaccess Maker's Backend Protection feature (only available in the for-a-fee Professional edition of our software).

Please read the commentary at the beginning of this section to understand more about what each protection mode helps you protect against. If unsure, always start with Everything and only downgrade to All PHP Files or Joomla temporarily, until the developer of the problematic extension can apply a workaround.

The Reset custom error pages option should be enabled unless you have a specific reason to not do that, e.g. your server gives you a 500 Internal Server Error when you use this feature. Many servers use custom error pages for HTTP errors, including the 401 Authentication Required and 403 Access Forbidden errors. The former is sent by your server to your browser to signal that a directory is password-protected. The latter is sent by your server to your browser when the provided username and password to unlock the password protection is wrong. If the custom error pages defined in your server configuration do not exist or are inaccessible it will result in a 404 error which is ultimately handled by Joomla's frontend. So, instead of seeing a prompt for the password protection's username and password you confusingly see a Joomla 404 error page instead! The Reset Custom Error Pages feature tells your server to NOT use any custom error pages, instead falling back to a simple and short, built-in error message. This prevents the confusing 404 error and lets the password protection feature work correctly.

To apply the password protection, enter a desired username and password and click on the Password-protect button. This username and password is common for ALL users who will be logging into your site's administrator backend. Furthermore, it MUST be different to your Joomla login information and should NOT BE OBVIOUS i.e. do not include the name of your site or any other text easily derived by someone taking a careful look at your site's public content.

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, as long as the browser hasn't cached this information. 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 .htaccess and .htpasswd files from your administrator directory (DO NOT touch the .htaccess file in your site's root!), or click on the Remove Password Protection button in Admin Tools' Administrator Password Protection feature.