XF 1.5 Two-Step Verification and Security Improvements

Account security has become a hot topic recently. There are seemingly endless stories about password databases from popular sites being leaked. Because password reuse is common, we've started to see brute force login attempts using these leaked passwords. Maintaining account security has become a big priority. To help this, we've added a few new features.

Two-Step Verification

Two-step verification, also known as two-factor authentication, requires you to provide two pieces of information to login. The general form is expressed as "something you know and something you have". "Something you know" is your password. "Something you have" is the new part. You may have seen this with other services, such as Google accounts. If you're familiar with that, you'll understand how it works in XenForo.

Two-step verification is something a user has to opt into sometime after they have registered. Enabling it increases security at the expense of a more complex login procedure. For many users--particularly ones that just lurk or only have a few posts--the "value" of their account is low so the cost may outweigh the benefit. However, for privileged users, the extra security should be worthwhile.

When you've enabled two-step verification, you will login with your username or email and password as normal. Once those are verified, we will determine if two step verification is needed. If so, you'll need to take the appropriate steps to complete that. Upon receiving that verification, you'll be logged in as normal.

Let's look at how each step works in more detail...

Two-Step Verification: Setup

two-step-setup1.webp
two-step-setup2.webp


To enable, you enter the two-step verification page from the account section. Note that you'll need to confirm your password before you can do any manipulation to the two-step verification settings.

To enable, you simply pick the method of verification you want to use. XenForo ships with two "primary" verification methods:
  • Verification code via app - this will use an app on your phone (such as Google Authenticator or Authy) to generate a 6 digit code. This code changes every 30 seconds.
  • Email confirmation - this will send a unique, one-time-use code to the email address associated with your account. This method is not preferred over the app-based verification because if an attacker has access to your account, they may also have access to your email. However, it's certainly better than nothing.
To enable any method, you will need to go through the verification process to ensure that everything works as expected. This prevents you from being locked out by a system you didn't successfully complete once.

You can enable multiple two-step verification methods.

The two-step verification "provider" system can be extended by third-party developers to add different methods (for example, YubiKey support, phone/text-based verification, etc).

There is also a third method that is automatically enabled when the first two-step verification provider is enabled: backup codes. These are designed to be saved for emergencies when you can't verify your login through any other method (if you don't have your phone, for example). Each backup code can be used once and you will be sent an email whenever a backup code has been used.

Two-Step Verification: Login

If you have enabled two-step verification, this covers logging in via the admin control panel and the public-facing login.

two-step-login.webp


After verifying your password, if two-step verification is required, you'll be taken to a page such as the one shown above. By default, the highest priority, currently enabled two-step verification method will be triggered. (The priority is set by the developer.) If you wish to use an alternative method, you can choose to do so for this login.

This also gives you the option to trust this device for 30 days. You may be familiar with this approach with other two-step verification systems. If you trust this device, you can log out and log in without being prompted to complete two-step verification for 30 days. This helps to mitigate the annoyance that two-step verification can create.

Once the 30 days are up, you will be prompted to complete the two-step verification again (even if you have chosen to stay logged in).

In the event that you want to stop trusting a device or you need to revoke that trust for other devices, you can do this from the two-step verification setup page in the account system:

two-step-trust.webp


Two-Step Verification: Losing Access

A common concern with two-step verification is what happens if you lose access to all of your two-step verification methods. We have attempted to mitigate that as much as possible.
  • Backup codes are really generated for this exact situation. If you lose your phone or your email is no longer valid, the backup codes will still work. However, this does require saving them once they're generated. This is something that not all users will do.
  • Disabling two-step verification only requires access to the password when you're already logged in. If users choose to trust a device, this very likely means that they will still have access to their account. Once they verify their password, they'll be able to change their two-step verification settings as necessary.
  • Finally, admins can see the current two-step verification status and disable it if necessary:
    two-step-admin.webp


Password and Email Change Notifications

Beyond two-step verification, we have also made several other small account security-related improvements.

Now, if your password is changed, you will receive an email to make you aware of this. Normally you can disregard this, but it serves to help notify you if someone is accessing your account and attempting to block your access to it.

Similarly, if your registered email is changed, you'll receive an email (to the previous address) to make you aware of this.



Password Reset Process Changed

The password reset process has been simplified to be more user friendly and not send a password via email. Once you receive the email for the password reset request, the link will allow you to set a new password directly. This is more in line with current approaches to password resetting.



That's all for today, but there's still more up our sleeves...

Just a reminder: Please do not post suggestions in this thread (even if you feel they are related). Use the dedicated suggestion forum so they can be tracked.
 
The QR code is for setup only. It encodes the data necessary to generate the code.

You may want to have a look at how it works with a Google account. It uses the same standard (TOTP).
 
It's not necessarily something that's required because of insufficient security on your forum:
Account security has become a hot topic recently. There are seemingly endless stories about password databases from popular sites being leaked. Because password reuse is common, we've started to see brute force login attempts using these leaked passwords. Maintaining account security has become a big priority. To help this, we've added a few new features.
 
Personally, I don't see a benefit in limiting who can use it given that it's an explicitly opt-in procedure. IMO, it should be a user's choice to add more security to their account.

That's perfect, then! Most of the staff will probably get on board with it and others users can try it as they see fit.
 
We haven't done anything to make it work with third party code so that's something that would need to be tested. It's possible there could be issues but it would be Tapatalk code that would need to be adjusted to allow that to work.

As ever we will be running a public beta and RC of XF 1.5 eventually. It's at that point you would get the opportunity to test it before rolling it out live to your site.
 
There are no user group permissions. Users will use it or not. The only thing we might consider, is forcing for certain usergroups, but at the same time we're not convinced that as a concept is workable.

I hate to say this, but a few forums of mine have an older membership, and some are not very computer savvy. Forcing a feature like two-factor on them would probably just frustrate them. For staff? Maybe. But it certainly is not a deal breaker. A feature like this I would actually prefer as an opt-in, to be honest.
 
@Mike and @Chris D (and the rest of the team), thanks so much for this. As one of the people who was sort of vocal about adding 2FA I couldn't be much happier about its addition in 1.5. I think this is a fantastic step and another case of xF being a forward-looking and security-conscious leader of the forum pack. Well done!

You know what is scary? Some of our first web forums had no registration at all. The old text based wwwboard and its derivatives like WebBBS you simply posted to. Kind of sad that we should even need two-factor, but that is the way of the Internet these days.
 
2FA is opt in. If someone doesn't want to use it or doesn't understand how to use it then that's fine. It doesn't affect them.

The forcing comments are in response to requests to give Admins the ability to force it on certain users/groups/roles. If that becomes a feature it certainly won't be enabled in any way by default.
 
2FA in the core is great - yet another level of protection for administrators/webmasters, if nothing else.

You know what is scary? Some of our first web forums had no registration at all. The old text based wwwboard and its derivatives like WebBBS you simply posted to.

Ah, back in the day of the dial-up BBS and my 1200 baud modem. I remember when I was the king with my 9600 baud modem
 
This is Great! :cool: (y)
I was just hoping the standard implementation would have support for Yubikeys already in it.
Google Authenticator doesn't work if you are traveling between different time zones.
Me and my mods use Yubikeys. Yubikeys are awesome, and so easy to use. They always work, also in different time zones.
I'm using an add-on for two-factor authentication now.
 
I skimmed the OP so forgive me if it is mentioned.

Is there any criteria set when a user makes use of the 2FA? I think this could be beneficial for user group promotions and even awarding trophies.

As for forcing a certain user group to use 2FA, I think this should be monitored by the admin. If you as a admin require it then staff members should abide if not then the staff member should be demoted until they comply. Adding a huge complexity to the feature when it can easily be handled otherwise just doesn't seem worthwhile in my opinion. Using a promotion (if implemented) you could easily see who has and hasn't used 2FA.
 
Last edited:
A criteria for using 2FA wasn't mentioned in the first post, I'd have to check to see if its an included feature.
 
A criteria for using 2FA wasn't mentioned in the first post, I'd have to check to see if its an included feature.

I did ask on the first page but hopefully it can be added in. It may sound silly but my users liked that we had trophies for the current one we use (as we have a graphic bar that changes to match our game based on trophy count).
 
The thing I love about XF after coming over from using the free open source forum engines is that XF is never playing catch up with features, they are always ahead of the curve and providing me with features I didn't even know I needed like improved security.

Any chance that you will consider supporting text message authentication? I feel like it would be a simpler process for the user than installing an app but I understand that it would be harder to support.
 
I would expect an add on developer would step up and release something that supports text messaging but bear in mind that kind of service would have a cost attached to it.

Admittedly not very expensive. But you will likely be charged per text message and that cost could mount up considerably.

The system has been designed to be extendable so the best thing you can do for now is post a specific suggestion in the suggestion forum and wait for it to come as an add on or commission that as a custom development request.
 
Top Bottom