![[Important]](/media/com_docimport/admonition/important.png) | 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 tool
of Admin Tools is designed to add an extra level of protection to your
site's wp-admin, asking for a username and password before accessing the
login page or any other file inside the wp-admin
directory of your site. It does so by using Apache .htaccess and
.htpasswd files, so it won't work on IIS hosts.
| Important |
|---|---|
|
Some prepackaged server bundles, such as Zend Server, 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. |
Password-protect Administrator
If you are on a server running on Windows™, you are receiving a warning at the top of the page stating that the password will be stored to disk unencrypted. This is done due to the lack of the system-wide crypt function on the Windows platform, which causes Apache to understand password only if they are unencrypted or encrypted with a non-standard encryption scheme which does not exist in PHP.
![[Warning]](/media/com_docimport/admonition/warning.png) | Warning |
|---|---|
|
If you password your administrator directory on a Linux system
and then restore your site on a Windows server (typical live to local
site restoration) you will be receiving a blank page or an Internal
Server 500 when accessing the site. This is normal and expected. All
you have to do is to remove the |
You have the following options:
- Administrator resources to protect
-
This option controls what exactly will be placed behind password protection.
Everythingis equivalent to how Admin Tools worked before version 1.7.0; all files underwp-admin, regardless of their file extension, will be protected by a password. This includes CSS and JavaScript files which may be used by third party plugins in the public front-end of the site.All PHP Fileswill only put files with a .php extension behind password protection. This protects against unauthorised access to your site's administration back-end, but does not prevent fingerprinting of your site i.e. an attacker would still be able to trivially identify your site as a WordPress site, and very possibly determine the WordPress version you are running within a very narrow range.Regardless of your choice here some core files, such as
admin-ajax.php, will always be allowed to be accessed directly without being subject to password protection. This allows third party plugins offering automation through WordPress' AJAX feature to still work, despite the password protection. These exemptions were added in Admin Tools 1.7.0 in late March 2025. - Reset custom error pages
-
The password protection works by having Apache send an HTTP 401 Unauthorized response to the web browser which will then ask you for a username and password. If the username or password is invalid, Apache will return an HTTP 403 Forbidden response to the web browser so that the browser can let you know your credentials were invalid.
Some servers set up custom error pages for HTTP error responses such as the aforementioned 401 and 403. If the contents of these pages are lengthy (typically: above 128 bytes) your browser may instead display the contents of the custom error page instead of presenting you with the necessary login dialog.
Further to that, if the configured custom error pages do not exist (the files they are pointing to are not present, or not accessible on your server) you may receive an HTTP 404 Not Found error page instead of a login dialog, which is very confusing.
This option addresses these problems by resetting Apache's error pages for HTTP 401 and 403 to its built-in defaults.
You are strongly advised to keep this option enabled unless it causes and HTTP 500 Internal Server Error problem.
- Username, Password, and Retype password
-
The username and password to use for the
wp-adminpassword-protection.We strongly advise against using a username which can be derived from your or your site's name, the name of any company or brand you are affiliated or fond of, or any information which can be conceivably discovered by an attacker such as but not limited to your phone number, email address, online handle, names of family members and pets etc.
We very strongly recommend using a password manager –such as the one supplied by your browser or Operating System– to generate and store long, random passwords.
Important DO NOT use your WordPress username or password! The username and password here is meant to be shared with everyone who needs to use the site's administration area including other administrators, network site admins (on a multi-site installation), editors, etc.
Even if you have what is effectively a single-user site you should use a separate username and password. The whole point is to add one more hurdle between an attacker and your site's administration. Having this identical to your WordPress login information beats this purpose, so you might just as well not use this feature…
- Password hashing algorithm
-
Passwords are stored hashed in the
wp-admin/.htpasswdfile. Hashes are one-way computer functions which produce the same, random-looking output when given the same password as an input. “One-way” means that deriving the password from their output is laborious enough to be practically impossible.Different versions of Apache may support a number of hashing algorithms. Some of the supported hashing algorithms are too rare to be of practical use, unsupported by PHP (the programming language WordPress and Admin Tools are written in), or too weak (the “one-way” promise is somewhat broken, allowing attackers to derive a working password given a hash). This leaves us with four options which are supported by Admin Tools.
bCryptis the most secure hashing method available. We recommend using it, unless your server does not support it. If you are unsure, ask your host if bCrypt is supported on your server for storing passwords in a.htpasswdfile for password-protecting directories.APR-1(default) is the best compromise. It is secure enough to be practical, and it is always supported by Apache 2.x. Please note that older versions of Apache are abandoned, and should not be used on production sites.SHA-1is always supported by all versions of Apache released the last 20 years, but it's no longer considered secure. A vulnerability in the hashing algorithm was discovered in the early 2010s which allows an attacker to find the password using fairly expensive hardware and a not inconsiderable amount of time. You should only use that if neither of the above methods worked.crypt()is a legacy algorithm which only supports passwords up to 8 characters long. If you use a longer password it will be truncated when creating the password-protection, but you MUST also be careful to NOT enter more than 8 characters when asked by your browser. If you enter more than 8 characters when the browser asks you your password will always be considered wrong. Moreover, this method is NOT supported on Windows. This method is mainly included for legacy Apache versions 1.x if all else fails. It is considered deprecated, and will be removed in a future version of Admin Tools.Finally, there's
Plain Textwhich does NOT apply any hashing algorithm. The password is included in the wp-admin/.htpasswd file as-is. Anyone with access to this file will be able to read and use the password. As such, it should NEVER be used for any purpose other than troubleshooting, with a throwaway password which should immediately be considered compromised (burned).
Below the form there are two or three buttons:
- Apply password protection
-
Applies the password protection by creating the
.htaccessand.htpasswdfiles in thewp-admindirectory. - Remove Password Protection
-
Shown if the WP Admin Password Protection is already in effect. Clicking this button removes the password protection by deleting the
.htaccessand.htpasswdfiles from thewp-admindirectory.![[Note]](/media/com_docimport/admonition/note.png)
Note You DO NOT need to fill in the form to click this button.
- Cancel
-
Takes you to the Admin Tools Control Panel page without applying any changes to the password protection of your site.
The first time you apply the password protection the browser will ask you to supply the username and password you just specified. You will need to check the box to “remember” your username and password. 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 receive an error page with the error code 403 Forbidden your browser is remembering and sending the wrong username or password. You will have to use its password management features to remove the memorised username and password for your site.
If you wish to remove the password protection you can either
remove both the .htaccess and
.htpasswd files from your wp-admin directory, or
click on the button if
you still have access to wp-admin from your
browser.
500 Internal Server Error when enabling this feature
If after applying the password protection you immediately receive a blank page or an Internal Server Error 500 instead of a password prompt, your server is not compatible with the password protection scheme you have selected (or with the concept of password-protecting directories in general).
In this case, the only way to gain access to your site's
administrator back-end is to remove the .htaccess
and .htpasswd files from your
wp-admin directory using an FTP application or the
File Manager in your site's hosting control panel. If in doubt, consult
your host about how you can do that before trying to apply the password
protection.
If those files do not show up in your FTP client, please create two blank files with those names and upload them to your site, overwriting the existing (but invisible) ones. This will remove the password protection so that you can regain entrance to your administrator back-end.
404 Not Found error page or WordPress error page when enabling this feature
Long story cut short: ask your host to disable Apache custom error pages for HTTP status codes 401 and 403.
But why does this happen? (Optional, detailed information; you don't have to read the next paragraphs).
When you enable password protection all you're doing is create a .htaccess file. This tells Apache, your web server, that the wp-admin directory is password protected. The next time your browser tries to access anything in that directory it has to send an HTTP Basic Authentication header that contains your username and password. If it doesn't, Apache returns an HTTP 401 status which, in turn, instructs the browser to ask you for the username and password (and then store it in its authentication cache for the browsing session). This is how your browser knows it needs to ask you for a username and password.
However, HTTP 401 is technically an HTTP error status. Apache has a feature called custom error pages. Depending on the HTTP error status returned (all 4xx and 5xx codes) you can configure Apache to return a static HTML page with custom content to the browser when it sends the error code. This holds true even for the 401 status described above. The real cause of the problem you are facing is that the configured custom error page does not exist. This causes Apache to internally report the file as missing. This breaks the authentication flow and would normally trigger a 404 Not Found error page.
WordPress' .htaccess file always asks Apache to redirect missing files to its index.php file. That's how permalinks work: the URL is not a real file, Apache hands it over to WordPress and WordPress figures out which post or page to display. If it doesn't know what to do with the URL, like in this unfortunate case, WordPress displays its 404 error page.
When you disable custom error pages for the 401 error code you let Apache communicate that status directly to the browser without WordPress interfering. This lets the password protection work properly. FYI, the aforementioned error will also take place if you use your hosting control panel's directory password protection feature. It is not caused by Admin Tools. It is caused entirely by your server's configuration. Also note that most hosts do let you define and reset custom error pages through the hosting control panel.
I used that and my public site is now asking for a username and password
You have a plugin which has placed its files inside the
wp-admin folder of your site. This is against
WordPress best practices. Check your browser's console to find the
offending plugin and report it to the WordPress Plugin Directory.