With 4.2, we now have a new way to authenticate our sites. Two-factor Authentication has grown outdated with many new authentication methods arriving, so along comes Multi-factor Authentication (MFA).
For over 9 years Joomla has had a Two-factor Authentication solution. Every user has a username and password, and for some sites they were also required to use a second authentication factor. It could be linking your account with Google Authenticator or Authy on your phone. You put in your user name and password and are then asked for a 6 digit code which is shown on your phone. It changes every 30 seconds and if the number on the screen and the number you type in the linked account are not correct, login is denied.
The approach that Nicholas K. Dionysopoulos (the developer who contributed the new Multi-factor Authentication feature) went with, is a “Captive Login” approach. First, you login to your user account. Before you can access the logged-in area of the site, you are shown another screen to validate your login—this is where the “Captive Login” happens. You can validate with any of the methods set up in your user account. Then, you are fully logged in and can proceed as usual
.Extra features implemented and considerations made
Users can have multiple MFA methods. One setup could be two WebAuthn keys (main and backup) and a classic six-digit code for use in an older smartphone which doesn't support WebAuthn dongles. This makes MFA more usable and more resilient to accidents that lock people out of their site.
If you have multiple authentication methods you don't want to stop and think about which method you will be using to authenticate today, especially since you're likely to use the same method 99% of the time. Therefore you can pick a default method. You can NOT use emergency codes, which can only be used once, as the default method to reduce the probability of silly mistakes.
Let's say you set up three WebAuthn authenticators. When you log in you want to see a single page asking you for a WebAuthn login, not having to click to select which WebAuthn authenticator you will be using.
WebAuthn and YubiKey let you set up multiple instances of that method, so instead of choosing which WebAuthn authenticator or YubiKey you want to use, you just select the method, e.g. ‘WebAuthn’. Then you can use whichever one of the authenticator / keys you have set up. Joomla will figure it out, as you'd expect from a professional Multi-factor Authentication solution. Regular Authentication Code and Authentication Code by Email only allow a single instance so they don't do method batching.
To support multiple MFA methods per user some restructuring of the Joomla tables was needed. The MFA data from the two #__users columns (otpKey and otep) were moved to their own table (#__user_tfa). Any already set up legacy Two Factor Authentication (TFA) method is automatically migrated upon first login. This means that MFA will migrate cleanly even on sites with hundreds of thousands of users, something which would not have been the case had the migration been performed during the update. This means that until a user goes through a login you will not see their TFA/MFA status or configuration settings in com_users in the backend.
The MFA configuration data is still encrypted using AES-256 using a key derived from the site's “secret”. Therefore a simple SQLi Vulnerability in any extension won't divulge the secrets for MFA.
You can now use Authentication Code by Email and WebAuth on top of the existing Authentication Code and YubiKey methods. The former sends you a 6-digit code to your email and can also be set up to be forcibly enabled for anyone (to provide a viable backup if your users are not very tech savvy). The latter supports Windows Hello and Android
You can optionally set up certain user groups to have MFA forcibly enabled and other groups to have MFA forcibly denied. Groups that have forced MFA will be required to set up MFA and use it to continue using the site. Groups that are forbidden from using MFA will never be asked to go through the captive login, even if they had previously enabled it, nor will they see the MFA configuration section in com_users.
You can optionally have users be automatically shown an onboarding page if they log in and they have not yet enabled MFA. They can set up MFA, go to a different page or forever dismiss the onboarding page. You can also customise the onboarding URL, e.g. if you want to display your own article instead of showing the default MFA setup page. According to Nicholas, this increases MFA adoption by a factor of ten. Note that onboarding is disabled by default.
As a Super User, you cannot change another Super User's MFA settings at all. Consequently, if a Super User gets their details wrong you will need to do some database editing.
Administrators can only remove MFA options for other users. As a privileged user, you can only remove MFA options from other (non-Super Users) user accounts, or disable their MFA completely. You cannot edit their MFA configuration or enrol new MFA methods.
The MFA configuration interface includes a Turn Off button which disables MFA completely for your user account. This is useful if you lost access to all MFA methods, you have used an emergency code and you just want to turn MFA off until you sort out your other problems.
You can choose which module positions to display in the captive MFA page. This lets you display, for example, your site's header and footer to give users a better visual experience.
In conclusion, with the new Multi-factor Authentication, Joomla 4.2 is packed with an expandable, secure authentication fit for the future.