This feature will prevent the creation of a user account whose username is one of the disallowed usernames.

The forbidden usernames are those which belong to the default forbidden username list, plus the Usernames explicitly forbidden set up below. However, any usernames in the Username explicitly allowed list below will not be blocked, even if it belongs to either of the previous two lists.

You can find the default list of forbidden usernames (1062 entries) in the file plugins/system/admintools/assets/forbidden_usernames.php.

Usernames in this list will not be allowed for new user accounts. These usernames are forbidden on top of those in the default list described above.

Usernames in this list will be allowed for new user accounts. Use this to add exceptions to forbidden usernames found in the default list described above.

When this option is enabled, Admin Tools will connect to the Have I Been Pwned database and check if the hash of the current password is known. If a match is found, the user will be blocked from using an insecure password.

Wait, are you sharing my password? Is that service secure?

First of all, we do not share your password. We're only sending a fraction (only first 5 chars) of the hash of your password. This method is called k-anonymity and it's a very secure way to share sensitive data without compromising its privacy. Your password CAN NOT be derived from this partial information. If you want to read the whole details of this implementation, you can take a look at this page.

Regarding the external service, it is powered by two well known figures: Troy Hunt (a security research) and CloudFlare (leader in Content Deliver System services). The service is so important for the security of computer systems that even the United States of America Federal Bureau of Investigation (FBI) contributes to it.

Most likely you want to enable this feature only for specific groups: Admin Tools will check for well-known passwords only users belonging to those groups (default is Super Users)

Joomla allows all users who do not have the Super User permission to request a self-service password reset. This is typically through the “Forgot your password?” feature in the frontend login module and the frontend users component, both of which go through the frontend users component to send an email to the user to help them reset their password.

In some cases it is prudent to disallow this feature for certain types of users. For example, you may have user groups which do not have the Super User permission but can be critical to the operation of your site such as people doing end user support, handle personal or privileged information, control content publication workflows etc. A successful account takeover could have far-reaching implications for the operation of your site and/or business.

This feature allows you to disable the self-service password reset feature for users belonging in specific user groups.

Please note that this feature DOES NOT control whether users with Super User permissions are allowed to reset their password! Joomla itself automatically disallows self-service password resets for these users and this cannot be changed (it's a hard-coded check no third party plugin can change). This means that Super Users cannot reset their own password using the Forgot Your Password feature; this has to be done either by logging in and editing their user profile OR by having their user profile edited by another user with sufficient permissions to edit user profiles. This is a built-in Joomla feature, not under the control of Admin Tools.

Finally, please note that this feature only applies to self-service password resets sent by Joomla's frontend com_users component. It DOES NOT prevent third party software implementing its own password reset feature from allowing these users to reset their passwords.

Choose the user groups which will be prevented from using Joomla's self-service password reset. Only visible and applicable when the “Disable password reset for specific User Groups” option is enabled.

Only users which are directly assigned a user group will be disallowed to reset their password. That is to say, you cannot just select the Public group and expect nobody to be able to use this feature; the restriction is NOT applied to child user groups.

Also note that you do not need to select the Super Users group or any other group which grants the Super User permission. Joomla itself automatically disallows self-service password resets for these users and this cannot be changed (it's a hard-coded check no third party plugin can change). This means that Super Users cannot reset their own password using the Forgot Your Password feature; this has to be done either by logging in and editing their user profile OR by having their user profile edited by another user with sufficient permissions to edit user profiles. This is a built-in Joomla feature, not under the control of Admin Tools.

When enabled, Admin Tools will prevent editing a user which belongs to or is added to one of the user groups set in the option below. This restriction applies to the backend, frontend, and API applications and cannot be overridden even by Super Users.

If you do not select specific user groups, Admin Tools will apply this restriction to all users who can log into the site's backend.

The idea behind this feature is that it provides an additional protection against privilege escalation, and cross-site scripting attacks. For example, a malicious user may exploit a vulnerability in your browser, browser extension, or email programme to trick you into visiting a URL while logged into your site as a privileged user so that a known user account is granted privileged access to your site (e.g. Super User), or a new user account with privileged access is created. With this protection in place this will be impossible.

Choose the user groups which will be protected by the “Disable editing user properties” feature.

If you do not select specific user groups, Admin Tools will automatically determine which user groups have backend login privileges and protect them.

If your site has user groups which have elevated privileges in the frontend or backend of the site such as e-commerce store managers, forum moderator, support ticket system user agents etc we recommend that you select these user groups in addition to the standard privileged backend user groups (for most sites that would be Manager, Administrator, and Super Users).

This feature allows to prevent creating or editing users from the frontend of the site, as long as this users belong to or are added to one or more user groups selected in the option below. The default (when no group is selected) is to prevent editing or creating users which belong or are added to any group which has backend access privileges.

The idea behind this feature is that you should not be able to create a new user with administrative backend login privileges from the public frontend, as this creates an opportunity for privilege escalation. That is to say, if an attacker finds a vulnerability which allows them to surreptitiously create new user accounts which belong in one or more privileged user groups (e.g. Administrator, Super User, etc), or add an existing user account to privileged user groups they would be able to convert a standard, unprivileged account into something much more powerful with detrimental impact to the security of your site.

This feature addresses some of the most notorious zero day attacks in Joomla! which took place between 2015 and 2016 and we recommend having it turned on at all times. If you need to disable it we strongly recommend rethinking whatever leads you to disable this setting because it's creating a gaping security hole on your site.

Select the user groups the Disable creating / editing users from the frontend feature above applies to.

If you make no selection, Admin Tools will automatically determine which user groups have backend login privileges and apply this feature to these user groups.

If your site has user groups which have elevated privileges in the frontend of the site such as e-commerce store managers, forum moderator, support ticket system user agents etc we recommend that you select these user groups in addition to the standard privileged backend user groups (for most sites that would be Manager, Administrator, and Super Users).

When this is enabled and someone tries to change the Global Configuration of Joomla!, either from the back-end or the front-end, you will either be notified or they will get blocked (depending on your settings below). This feature is designed to protect you against sly hackers or malicious administrators who subtly change your site's configuration for nefarious purposes, e.g. by elevating the global privileges of user groups.

When this is enabled and someone tries to change the configuration of any core Joomla! or third party component (what you see when you click Options in a component's toolbar) from the back-end of your site you will either be notified or they will get blocked (depending on your settings below). This feature is designed to protect you against sly hackers or malicious administrators who subtly change your components' configuration for nefarious purposes, e.g. by elevating the privileges of user groups with regards to a particular component.

This option works in conjunction with the two above. You define what do you want to do when either global or component configuration is enabled and a change is detected in the configuration.

Critical files commonly modified by hackers (index.php, administrator/index.php and the index.php, error.php and component.php of all templates installed on the site) will be monitored for changes on every page load. If a change is detected, an email will be sent to the email addresses configured in Email this address on blocked request. This usually lets you get an ahead warning in case of a successful hacking attempt.

Admin Tools checks these files every time your site loads a page. The size of the file, the file's last modification date, the MD5 checksum of the file's contents and the SHA-1 checksum of the file's contents are calculated by PHP and compared against the information stored in the database table #__admintools_storage (where #__ is the common table name prefix of your site, as defined in your site's configuration.php file), in the row with the key criticalfiles. If any of this information has changed since the last request to your site, Admin Tools considers the file changed and triggers an email to you about changed files. Every time a change is detected the aforementioned information for each file is updated in the #__admintools_storage database table. This way you will not get any further e-mails about the changed file unless it changes once again.

It is possible for an external application or process to modify these files, then restore them back to their previous state — including the last modified date. If a request to your site takes place while any of these files is in a modified state you will receive an email. This may be perceived as a “false positive” because by the time you check your site again the change has been reverted. This is NOT a false positive, something really DID change. Admin Tools deliberately sends you an email because this is something which can also happen during a legitimate attack: the attacker modifies one of these files to gain access to your site, then covers up their tracks by restoring the file to its previous state.

It is also possible that you will receive an email if someone or something modifies the #__admintools_storage database table row. In this case the contents of the database table may not reflect the files currently on the server's filesystem. As a result, Admin Tools perceives the files as changed. For example, this may happen if the host automatically rolled back the state of your database or when you restore a database-only backup / SQL dump of your database.

Finally, you will most likely receive this kind of email after updating the Joomla version on your site, after updating your site's template, and after updating the Global Configuration of your site — even if this happens automatically without your interaction. In both cases some of the critical files have changed. When you update Joomla its index.php files are changed. When you update your template its index.php, error.php and component.php files are changed. When you save your site's Global Configuration —or a third party extension or external software updates your site's Global Configuration— the configuration.php file is changed. These are expected changes. If they happen without your knowledge you should track down what is causing them and decide whether it's acceptable behaviour or not.

Monitor the following files (one per line) for changes. If a change is detected, an email will be sent to the email addresses configured in Email this address on blocked request.

The file paths must be entered relative to the site's root, without a leading forward slash.

Admin Tools will keep track of the user accounts with Super User access. If a new Super User is added outside of Joomla's Users page, an email will be sent to the email addresses configured in Email this address on blocked request. Moreover, the detected new Super User accounts will be automatically blocked. The idea is that these Super Users are most likely create as the result of a hack or rogue code.

Please note that users created or added by other Super Users in the backend of the site using Joomla's Users page will NOT be blocked by this feature. If you wish to disable this please use the Disable editing backend users' properties feature.

When enabled, Admin Tools will disable the Joomla! Two Factor Authentication (2FA) / Multi-Factor Authentication (MFA) configuration for a user when they are resetting their password.

Joomla! allows every user of the site to enable MFA for their user account. In case the user misplace their MFA device or is otherwise unable to use MFA they are given emergency one time passwords. However, many people forget to note them down or do not understand how to use them. Every time they cannot use MFA they have to contact an administrator of the site to disable MFA on their account. Even worse, when the user is a Super User themselves they have no way to disable MFA without editing the database. This is where this Admin Tools feature comes in handy.

The workflow is the following: The locked out user starts by using the "Forgot your password?" link in Joomla! to request a password reset. The receive an email with instructions. They follow the link which takes them back to the site where they enter their username and the password reset authorisation code found in the email. Now they enter their new password. When the password changes, the "Disable Joomla!'s Two-Factor Authentication on password reset" feature of Admin Tools kicks in and disables MFA on this user's account. The user can now log in to the site using just their username and password.

When enabled, it will not be possible for Super Administrators to log in to your site's front-end. This is a security precaution against password brute forcing. One common method is an attacker trying to login to the front-end of your site as a Super Administrator, trying different password until he finds the correct one. When this option is enabled, he will not be able to log in as a Super Administrator in the front-end of the site, crippling this brute forcing method of determining the Super Administrator password.

When enabled, failed login attempts of any kind of user (even simple registered users) count as a reason to block the request and are being logged in Admin Tools' Blocked Requests Log. There is a very useful implication to that. Since they count as security blocked requests they count towards the limit you set up in the automatic IP blocking. Therefore, after a number of failed login attempts, the user's IP will be automatically blocked for the duration you have set up.

By default, when a failed login is treated as a blocked request no other information is logged except the IP address of the failed login. This is very unhelpful if a user gets blocked and they can't figure out what is their IP address. Enabling this option will also log the username they used for the failed login. The downside is that your Blocked Requests Log now contains the usernames of all failed logins which can be a privacy issue if the log file is leaked to an attacker or other unauthorised person due to a vulnerability in a third party extension or by a mistake by one of the administrators of the site.

Please note that Admin Tools WILL NOT log passwords for failed logins and we WILL NOT consider any feature request to implement this kind of option. If were to log failed logins' passwords we'd be essentially storing a password the user may be using on a different service OR a slight variation of their real password in plain text in the database. This can be a major security concern.

Admin Tools can optionally deactivate existing user accounts when there are multiple failed attempts to log in using their username, protecting user accounts from brute force attacks. In here you can specify the number of failed logins and the time period these have to occur before the user is deactivated, e.g. 3 failed logins in 1 minute.

In order for this feature to work you must have enabled the Treat failed logins as a reason for blocking the request option above and NOT include Login failure in the Do not log these reasons option in the Logging And Reporting area of this configuration page.

The behaviour of this feature depends on the user registration setup of your site, as defined in Users, User Manager, Options in your site's back-end. When Allow User Registration is set to No this Admin Tools feature does not do anything at all! When Allow User Registration is set to Yes there are three possible behaviours depending on the setting of the New User Account Activation option:

There are three further options, Number of failed logins, Failed logins period, and Unit of time measurement which control after how many failed logins in which period of time the account will be disabled.

Display a message in browser console to warn the user to avoid running any command inside it. This can lead to hacking yourself (a.k.a. Self XSS attacks) and steal your account data.

Admin Tools can block user registration based on the email domain they are using (listed in the field below):

Enter one domain per line. Having no non-empty lines disables this feature.

Should this feature be enabled at all?

For performance reasons, this feature only runs periodically, checking which backend user accounts are inactive and disabling / forcing a password reset on them. Here you can define how often it will run. The default is 60 minutes which means that it will run at most once every 60 minutes. Other useful values are 1440 (at most once a day) and 10080 (at most once a week).

Which user groups this feature should apply to? We recommend choosing at the very least the Administrator and Super User groups. If you have other user groups with backend login we recommend you add them as well.

If you do not specify any groups, or choose the "Show All Groups" option, Admin Tools will consider users from all user groups which have the Admin Login privilege, as set up in the Global Configuration of your site.

Even though you can select user groups without backend access they are NOT taken into account. The user groups list is rendered by Joomla! and it does not provide a way to remove user groups which lack backend access.

Users who have not logged into the site for at least this many days will be blocked or forced to reset their password. The default is 90 days (three months). Reasonable values are between 30 and 365 days. If you set this to 0 or leave this blank the feature will effectively be disabled.

What should Admin Tools do with the user accounts which have not logged in for a long time?

Block means that the user will be completely blocked from accessing the site. This is implemented by setting the Block User to Yes. The blocked users cannot unblock themselves. A Super User will have to do that by editing the user from the Joomla backend Users, Manage menu item.

Force Password Reset is the recommended and selected by default method. In this case the user account is allowed to log in but they will have to immediately reset their password and log back in before they can do anything on the site. The password reset takes place through Joomla's built in password reset method. It is NOT handled by Admin Tools.

Any users you select here are not going to be prevented from logging into the site. We recommend that you add the site owner here. Moreover, if you are building a site for a client, you should add your user account as well. This will let you log into the site to provide technical assistant should your client require it.

It is worth noting that if Login prevention method is set to Block and Protected Users is empty Admin Tools will NOT block ANY Super Users, even if they haven't logged in for a time period longer than the specified maximum number of days. This is a precaution against losing all access to the site by accident (if all Super Users get blocked then nobody is left to unblock you). If you have a site with multiple Super Users and use the Block method you MUST specify at least one Protected User for Admin Tools to provide a sensible level of protection against forgotten user accounts.

Controls what happens when a user enables login with passkey on their account.

The reason this feature exists is that passkeys are far more secure than passwords coupled with Multi-factor Authentication (MFA). Passwords can be guessed or stolen. Many forms of MFA can possibly be defeated either with a brute force attack, or with a “spearphishing” attack. In the end of the day, MFA is only as strong as the weakest link – and having recovery codes is exactly that, so even if you use passkeys as your MFA it might not be as safe as you would like it to be.

Using passkeys for logging in instead of a password, on the other hand, is the most secure method possible. The passkey is cryptographically tied to the specific user account, enforces the use of HTTPS, and the web browser validates you are on the correct domain thereby making phishing attacks impossible. Again, this is only as strong an authentication option as the least secure authentication option available for your user account. If that option is a password, you are not safe. Hence the need to disable password logins and why this feature exists.