Two-factor authentication updates in ProcessWire 3.0.159

ProcessWire 3.0.159 brings some useful and time-saving upgrades to the core two-factor authentication system.

Ever since we added support for two-factor authentication to ProcessWire in 2018, like many of you, I’ve been using it religiously. Specifically, I use the TOTP authenticator (TfaTotp module) as I think that’s the best way to go, both for security and for convenience. Plus the TOTP mobile app selection is pretty nice: Authy, Google Authenticator, Microsoft Authenticator, LastPass, and others.

Considering the security benefits that it brings, two-factor/multi-factor authentication is something that I think we should make as easy and pain free and possible, thereby increasing its usage and thus the security of ProcessWire installations. But there are 3 issues that I think can be obstacles here. The first one we’ve got a solution for this week, the next one is coming shortly, and the 3rd is more an idea and question for you. So let’s jump in…

1. Finding and entering a code on every login can be a hassle

Finding the code and entering it as part of a login is definitely a worthwhile hassle, but for a lot of people it prevents them from adopting TFA/2FA/MFA, thereby reducing security. To answer this, ProcessWire 3.0.159 adds support for a “remember me” option in the system.

When you have TFA enabled (any kind), on the login screen where you enter your code, it now gives you a checkbox asking if you want to remember the computer:

screen_shot_2020-06-05_at_2_55_42_pm.png

When you enter the correct code and check the box, it will now remember your computer/browser with a cookie containing a long random series of bytes. The secure cookie is really the key here, but in addition to the cookie, it also remembers a fingerprint of your web browser at the server side. If anything about the cookie OR the fingerprint changes, then you are no longer “remembered” at login, and have to enter your code again.

Below are the options for fingerprinting your browser, which are configurable in the ProcessLogin module settings:

  • User agent
  • Non-versioned user agent*
  • Accept header*
  • Request scheme*
  • Server hostname*
  • IP address
  • Forwarded or client IP address (like for AWS ELB)

Items marked with an asterisk above (*) are what we use by default for the browser fingerprint. If your users primarily work from static IP addresses, then of course the “IP address” option would be a good one to select. Outside of that, the default selections are likely to be a good fingerprint for most.

screen_shot_2020-06-05_at_2_56_55_pm.png

Up to 10 unique browser cookie and fingerprint identities are maintained per user. If a user changes their password or email, then that clears all the identities. But a user can also check a box in the user Profile screen to clear it themselves, should they want to:

screen_shot_2020-06-05_at_2_54_27_pm.png

2. Many won’t use two-factor authentication till you force them to

ProcessWire hasn’t had an option to force users to use two-factor authentication, but likely will by next week. The only way you can really enable two-factor authentication for someone without making them do any work is to use an email-based two-factor authentication. At least in PW, email is a default field for all users, so it’s something we can reliably use here.

Granted, email is not as nice and secure as using something like Authy or Google Authenticator (TOTP authenticators you’d use with TfaTotp), but email is something that everyone has, everyone knows how to check, and still a MAJOR security improvement over not having TFA. That’s why you see many companies now using it by default on user logins, regardless of whether you’ve enabled 2FA/MFA.

To make this possible, I’ve made some updates in the core this week to support the option, and then have been updating our existing TfaEmail module to support using the user’s existing email address, among some other changes.

I didn’t think it was practical (or nice) to force TFA upon users until we had a “remember me” option, so that’s why that part was built first, and is now fully functional.

Here’s how it’ll work. You’ll install the TfaEmail module, and in the ProcessLogin module settings, you’ll be able to select the roles that TFA is required for (like you currently select the roles that TFA is “recommended” for). When a user logs in and has TFA required, then they’ll see the auth-code screen, along with a message telling them to check their email for the code. At this point, users may also select the “remember me” option.

3. Two-factor auth setup should be as turn-key as possible

Enabling TFA in ProcessWire currently involves downloading, installing and configuring one or more Tfa modules (like TfaTotp or TfaEmail). Then after you’ve done that, you enable it in the ProcessLogin module configuration (Modules > Core > ProcessLogin > Settings).

It’s all fairly easy and fast, but we could save the most time consuming step by just making TOTP and Email as core TFA modules. This would make it quite a bit more “turn-key”, moving a lot of it to an “install” button. I’ve been thinking that putting them in the core would increase the adoption rate of TFA, and thereby increase security for many PW users.

On the other hand, a competing goal is to make the core smaller, not larger, and I tend to be shy about adding new modules to the core. So if we go this route, we may want to remove a couple of lesser used core modules, or at least indicate them as being on the chopping block for PW 3.1. Modules like MarkupPageArray, MarkupPageFields, TextformatterNewlineUL, TextformatterPstripper, and FileCompilerTags seem like good candidates to move out of the core and into the modules directory.

What do you think? Move the two-factor TOTP/authenticator and Email modules into the core, or is it maybe better to continue maintaining them as 3rd party modules?

By the way, for those using LoginRegisterPro, all of the TFA improvements (like the remember-me and force-enable TFA options) will soon be coming to LoginRegisterPro as well. We just need to get the core support up and running first.

Other recent core updates

With this pandemic and having kids home all of the time, I’ve not been able to write blog posts as often, but still have been doing weekly updates in the forum News & Announcements boards. Just in case you’ve missed those, here are links to the recent core version summaries:

ProcessWire 3.0.156 core updates
A lot of GitHub issue reports were resolved, plus several minor tweaks and additions were made in 3.0.156 as well. But the biggest update was the addition of the $pages->parents() API…
See also: ProcessWire Weekly #314

ProcessWire 3.0.157 core updates
Covers major core refactoring of the Database and PageFinder classes. Plus an overview of why this kind of refactoring is important to the quality of the core, along with reasons why it has been and will always be part of our long term core strategy.
See also: ProcessWire Weekly #315

ProcessWire 3.0.158 core updates
Continued major long term quality improvements for the core, but no shiny toys to play with… Just lots of good and solid foundational core improvements, and a few fixes too.
See also: ProcessWire Weekly #316

So long as this pandemic work schedule continues, I’ll likely stick with this style of weekly updates in the forum, along with monthly (or thereabouts) updates in the blog, as that gives me a little more time to focus on the core development. Thanks for reading and enjoy reading the ProcessWire Weekly too!

Comments

  • HMCB

    HMCB

    • 5 years ago
    • 62

    Move it to the core. Positives outweigh the negatives.

  • Pete

    Pete

    • 5 years ago
    • 22

    These improvements are great, and the email option would definitely be used by one of my customers over the app so that's good. Also depending on the site I like having the option to set the number of days to remember the user for.

    I think TFA should be core because a main selling point for ProcessWire is rock solid security. I understand the hesitation as not many people may think about it but we SHOULD because most of us are building business websites I think, and a defaced website can lose us business and clients pretty easily. If go as far to say there could be something on the installer to prompt us to consider switching it on.

    As for removing stuff to make room for it, I'm not sure. ProcessWire historically hasn't done breaking changes if it can be helped so would either have to be v 3.1 with some way maybe of detecting if those modules had been used (a 3.1 readiness checker module maybe?) or just love with the core getting slightly larger. It's surely not adding too much overhead after all?

  • MrSnoozles

    MrSnoozles

    • 5 years ago
    • 21

    Nice. The 2FA additions will be useful but I' especially happy about the ongoing refactorings and improvements. Great work.

 

PrevProcessWire 3.0.154 and 3.0.155 core updates

This post covers a few of the bigger updates in ProcessWire 3.0.154 and 3.0.155 on the dev branch. This includes a new function for live replacement of text in core and modules, a new method for creating canonical URLs, and some major upgrades to our $input->urlSegment() method that I think you’ll like! More 

NextPowerful new text-searching abilities in 3.0.160

6

In ProcessWire 3.0.160 we’ve got some major upgrades and additions to our text-search abilities. This brings a whole new level of power to $pages->find() and similar API calls, especially when it comes to search engine type queries. More 

Latest news

  • ProcessWire Weekly #553
    In the 553rd issue of ProcessWire Weekly we'll check out the latest weekly update from Ryan, introduce a new third party module called Text Synthesis, and more. Read on!
    Weekly.pw / 14 December 2024
  • Custom Fields Module
    This week we look at a new ProFields module named Custom Fields. This module provides a way to rapidly build out ProcessWire fields that contain any number of subfields/properties within them.
    Blog / 30 August 2024
  • Subscribe to weekly ProcessWire news

“Yesterday I sent the client a short documentation for their ProcessWire-powered website. Today all features already used with no questions. #cmsdoneright—Marc Hinse, Web designer/developer