Blog post: 2-factor authentication and PW

[ryan]

This week we’re going to discuss a new security feature that’s currently in development on the dev branch: 2-factor authentication. In this post we look at the benefits of 2FA, how it works, the coming implementation in ProcessWire, and more: 

https://processwire.com/blog/posts/2-factor-authentication-coming-to-processwire/

[netcarver]

Yes! Very pleased to see this finally make it into the core. Thanks for mentioning my old module too - as it happens, I'm still using it, and just updated it to work with PHP7.2.

Thanks, Ryan.

[adrian]

Thanks Ryan!

While I think this is a great idea in principle, I can't honestly see any of my clients wanting to use this. I guess at least protecting superuser accounts will be a nice improvement.

Does anyone else think this will be a hard sell to clients, or do you think they will be really keen to use it? Maybe I need different clients ?

[netcarver]

@adrian

I guess it will vary. I can't see people with smallish brochure sites wanting it.

However, I'm currently using PW to build an admin system for a charity. Most of the users are probably using their (child|spouse|pet)'s name + a year of birth as their password, yet they are trusted to handle their own client's confidential information on the system. I see 2FA as a big win for this kind of user, as a small change in log-in protocol can bring in a big benefit for the charity and its clients, by mitigating the risk of such poor passwords.

[szabesz]

I reckon superusers will have the option to force 2FA upon all users, won't they? So far it sounds like this bit is not yet implemented, quote:
"Once enabled, individual users CAN ENABLE 2-factor authentication for their account in the ProcessWire user profile editor."

[pwired]

Why does it need to be in the core and not a module ?

[Gideon So]

Tried to download the Google authenticator but comments show that it is not very popular among users. One of the most common complains is that you will lose all your keys when you switch to a new phone and then you cannot login all the 2FA accounts.

Gideon

[szabesz]

10 hours ago, pwired said:

Why does it need to be in the core and not a module ?

From the blog post:
"This will enable us to support different types 2-factor authentication and different providers. Much in the same way that we support different types of email providers with WireMail modules."

I think there must be API based support to make individual authentication methods easier to implement.

[wbmnfktr]

Instead of assuming clients won't need or want this kind of feature I asked some of my clients today already and some of those who have more than 1 or 2 editors are welcoming such a feature. 

There are concerns but those shouldn't be the problem as I think that Ryan and therefore ProcessWire will take care of those things.

The concerns were:

• the possibility of a reset for already saved tokens (I don't know how and if this will work with the Google app)
• the possibility to reset passwords and disabling 2FA for a user
• the possibility to have exact one user to maintain those settings
• the possibility to enable/disable it site-wide with a config-entry

One client (a one-man business) asked if it's possible to remove username/password and just use this kind of token to login. 

I personally would use this on my personal sites but won't use it on client sites, as this part could end in an extra amount of work for me.

[ryan]

Quote

I reckon superusers will have the option to force 2FA upon all users, won't they? So far it sounds like this bit is not yet implemented, 

I don't plan on forcing the option, though had thought that when enabled, we'd give them a login warning notification asking them to enable it, every time they login. I haven't come across any services that forces me to 2FA yet, though I know some companies require it internally. But I think it might depend on the 2FA method being used before you could say if it would be a good idea to force it or not. There are times where you might want to disable 2FA temporarily too. So I think it's best to let the user control it, and maybe annoy them a bit with warnings when they aren't using it. But this is one of those things where I think we'll start fairly simple, but then start fine tuning the options according to what we find are the needs of people using it. 

Quote

Why does it need to be in the core and not a module ?

I think support in the core is consistent with PW's strategy of making security the top priority. I think we are soon reaching the time (or already have in some cases) where 2FA is considered essential in order for an online application to be taken seriously as having an emphasis on security. I consider it essential for any other online account I maintain (as I imagine many do), so it should be in PW too. If we step outside the security aspect, I think it also builds trust and checks boxes for a lot of bigger companies that may be considering PW or comparing to other options. 

The support and interface for it will be in the core. The implementation of the interface will be in modules. There will very likely be one implementation module included in the core, though I'm not 100% positive on that yet. Either way, I'll be building and maintaining at least one of the modules that supports it. 

Quote

Tried to download the Google authenticator but comments show that it is not very popular among users. One of the most common complains is that you will lose all your keys when you switch to a new phone and then you cannot login all the 2FA accounts.

As I understand it, Google Authenticator is just a standard implementation of RFC 6238 and RFC 4226, like any number of other authenticator apps. As far as I know, they are compatible with each other, but Google Authenticator is just the most widely known/used. I think the compliant you mentioned is the nature of the technology, and not really anything about Google Authenticator in particular. But the complaint is also the reason why it's secure. Once one understands how it works and the steps they should take, I think it all make sense. I'll try to describe. 

The reality is that 2FA is an extra step, which you can't deny is an inconvenience.  But it's like locking your door before you leave the house. Nobody likes having to take extra steps, what they like is the security benefit (if they understand it). And if you lose your keys, then yes you are locked out, unless you've got a backup method. This is why services typically provide backup 2FA methods (like SMS) or one-time use backup codes that you can store securely somewhere in case you ever lose your device. 

For every place where you use 2FA, you've established "a secret" between your device and the service/website (a long base32 string, which can also be represented by a QR code image). The reason it is secure is because it's not shared anywhere else. If that secret were stored up in the cloud or synced between devices and such, then it is becoming less secure. It is getting passed around networks just like your password, which kind of defeats the purpose of 2FA. 

If you buy a new phone, and can't restore backup data from your old phone for some reason, the yes you'd want to reset your 2FA for the new phone. If you've got your old device handy, then you'd switch the 2FA to your new device. If your old device is lost or non-functional, then this is where a backup method and/or one-time use code would come into play. If those options weren't available, when it comes to PW, one could also fix any of this by asking a superuser to reset it even temporarily disabling from $config (if nobody had admin access). 

Quote

the possibility of a reset for already saved tokens (I don't know how and if this will work with the Google app)

As I understand it, this is simply a matter of a user 2FA off for some account, then turning it back on, so they can establish a new secret/QR code.

Quote

the possibility to reset passwords and disabling 2FA for a user

There's already a password reset module built into PW. 2FA can be disabled for any individual account as needed. 

Quote

the possibility to have exact one user to maintain those settings

This is what the superuser account is for. ?

Quote

the possibility to enable/disable it site-wide with a config-entry

This is definitely part of the plan. Though with the 2FA methods I've been working with, we can't enable it for anyone that hasn't set it up themselves. Maybe with Netcarver's PPP module when using email, it could work. Or maybe it would work with SMS when you've already got the user's mobile phone number stored. 

Quote

One client (a one-man business) asked if it's possible to remove username/password and just use this kind of token to login. 

It needs to know the user name in order to be able to look up the user-specific secret for the codes. Technically it doesn't need the password. But 2FA without a password is no longer two-factor, and would have its own security problems, which might be even worse than not having 2FA in the first place. If someone gets a hold of your device, and needs no password for your account, then they essentially have access to your account. Whereas, the intention with 2FA is that both your password AND your device are necessary. It's that combination of factors that makes it secure. 

 

[wbmnfktr]

5 minutes ago, ryan said:

Quote

the possibility of a reset for already saved tokens (I don't know how and if this will work with the Google app)

As I understand it, this is simply a matter of a user 2FA off for some account, then turning it back on, so they can establish a new secret/QR code.

This is exact what the client is asking for. So it seems to be a perfect fit for them.

6 minutes ago, ryan said:

Quote

the possibility to enable/disable it site-wide with a config-entry

This is definitely part of the plan. Though with the 2FA methods I've been working with, we can't enable it for anyone that hasn't set it up themselves. Maybe with Netcarver's PPP module when using email, it could work. Or maybe it would work with SMS when you've already got the user's mobile phone number stored. 

I guess they want kind of a soft force to motivate the editors to use 2FA. In this case they might actually prefer the e-mail way as the users/editors use their corporate e-mail addresses. 

9 minutes ago, ryan said:

Quote

One client (a one-man business) asked if it's possible to remove username/password and just use this kind of token to login. 

It needs to know the user name in order to be able to look up the user-specific secret for the codes. Technically it doesn't need the password. But 2FA without a password is no longer two-factor, and would have its own security problems, which might be even worse than not having 2FA in the first place. If someone gets a hold of your device, and needs no password for your account, then they essentially have access to your account. Whereas, the intention with 2FA is that both your password AND your device are necessary. It's that combination of factors that makes it secure. 

I can totally agree with that.

I personally think that the 2FA could be a perfect thing to remove the password but keepign username of course (in this case) - the password is so often a problem. I know that removing the password makes 2FA kind of weak but replacing the password with a one-time-token could although be a nice option for those who don't play nice with passwords. ?

We will see and I will try 2FA with some of my clients.

[gmclelland]

I'm looking forward to the 2FA updates.  I'm hearing of more and more companies forcing 2FA with their email systems(GSuite or Office365).  We've had these discussions and will probably do this at our company as well.   Once people start getting used to using it with their email and banks, they will start to expect it with their websites as well.  I agree with Ryan, I think it will look good if Processwire already has this security built in.  It builds trust with larger organizations.

As a website administrator, I currently have to set up a secure password for each of my site editors so they don't get hacked.  I can't rely on them doing it.  I also have to disable them from reseting their password to something easier to remember.  With 2FA, I don't care what they set their password to.

It would be nice if we could somehow require/force 2FA for specific roles like Site Editors.

I'm not sure if this is a different technology then 2FA, but when using G-Suite, you also have the option to use the Google Prompt. https://support.google.com/accounts/answer/7026266  This makes it much easier to sign into accounts.  I wonder if that is just a Google thing, or if that is something that Processwire can utilize as well?

They also offer several different ways to authenticate https://support.google.com/a/answer/175197?hl=en including Yubi Keys, Google Authenticator App, Google Prompt, SMS text message codes, and backup codes.

[ryan]

I usually post to the blog on Fridays, but I've been working on ProcessWire-based client projects this week, so nothing new to post today. I'm back to working on the core next week and continuing the 2FA development, so will have more next week. Thanks and I hope that you have a great weekend.

[strandoo]

I've just been playing around with the TfaEmail module in conjunction with the LoginRegisterPro module. I've got a client who wants to upgrade their simple user registration/login system to use TFA (users request an account and if approved can access proprietary content and downloads). I thought the Email/SMS route would be the simplest and most familiar method. It works fine with just an email address (see below for SMS).

The site already has about 60 registered users, all with valid email addresses. I'd like to be able to transparently upgrade all accounts to TFA, so I thought I could copy their email address to the 'Email/SMS two-factor authentication' field. The problem is that if I do that and save the user, a code gets sent out (which would seriously worry/confuse the user!)

Is there a way to avoid this? Maybe disable something while I update the email fields? Or should I do this programmatically when a user logs in for the first time after in the front end? Maybe copy the email address 'behind the scenes' along with a notice of some sort? I guess I'm trying to skip the initial confirmation step of the TFA.

Once that's solved, I plan to allow the users to decide whether they want to continue using an email address or change to SMS message for authentication. I'll offer the option on their profile page. If they choose SMS, I'll use a service like ClickSend to send (I've had trouble finding free gateway numbers for the UK mobile carriers). In that case, I'd try to hook into the TfaEmail module to append the '@sms.clicksend.com' to the mobile number provided.

 

[strandoo]

Here's a follow up (see above):

I've been able to partly update my existing registered users with the API. I've enabled tfa_type, but can't set their tfa_code_email. That means that when they first log in, they'll see a notice telling them to configure TFA by entering their email address and receiving a code. That's not horrible, but that means they may not set it up if they are lazy. I'd rather already have their email address set so they'll just receive the 'we've sent you a code...' message and do it. So any thoughts about pre-populating this tfa_code_email field (it's a module setting) would be helpful.

I've added an admin confirmation system by adding another role (Ryan suggested this in another forum post) and hooked after the 'LoginRegisterPro::createdUser' method to notify the Administrator by email (with options to approve or deny as links that process the user without going into the CMS; this then notifies the User if successful). I've also hooked 'Users::saveReady' to send the same email, in case the Admin approves manually in the CMS.

Finally, I've given the registered users a choice of receiving their TFA code via email or SMS text message as mentioned above. ClickSend is affordable and easy to use. I've added radio buttons for 'Email' and 'SMS' to the User template along with a telephone field so users can choose when they edit their profile. 'Email' is the default, but if 'SMS' is selected, that phone number is prepended to the @sms.clicksend.com and replaces the email address via a HookBefore 'TfaEmail::emailCode'. I'm not great with Hooks, but it all made sense eventually and was a learning experience. I've simplified some of the interface on Edit Profile with 'display: none' in css (not ideal). But it all works pretty well. ?

 

[teppo]

Hey @ryan. Just a quick heads-up that I opened an issue at the TfaTotp GitHub repository about the required code format: if the app provides a code such as "123 456", TfaTotp requires me to type it in as "123456" for it to work, i.e. the app-provided format won't let me log in and the error message just states that the code was wrong.

Seems like something that should be handled by the core or the TFA module (not sure which handles taking in the input).

[androbey]

Hi all, 

I am once again seeking for help or at least some hints. I have the following "problem": 

I want to allow users to enable two-factor authentication from the frontend. So they should only be presented an option to enable TOTP (display QR code/secret and code input element) - no other profile edit related stuff is needed. 

I looked at the "TfaTotp" module class and I am not sure if one could use it in the frontend at all (as it seems to heavily rely on the user profile form in the backend). 

So my main question is: Is it possible to use this class for my usecase in the frontend without changing the code / duplicating it? 

 

[asbjorn]

As of today, the email sent contains the TFA-code alone. Is it possible for a function to add the timout, such as:

"The code will expire at 08:00:35 (HH:MM:SS)" or something similar?

I have older users for a project, and many do think the code has expired when sometimes the email takes a while to reach the inbox. So an expire timestamp would help along the way.

[dragan]

On 7/22/2018 at 4:58 PM, ryan said:

Quote

the possibility to reset passwords and disabling 2FA for a user

There's already a password reset module built into PW. 2FA can be disabled for any individual account as needed. 

I have a PW installation, where I activated 2FA for myself as superuser. Recently, my phone for some reason deleted several apps - one of them being Google Authenticator. I know how to reset a user password, but that won't help me in that particular situation.

@ryan

Is there an API method to deactivate 2FA for a certain user? In the docs, I only see $user->hasTfa().