For reasons that are stated in #29 the app passwords component needs a refactoring. What seems to be the best solution is the creation of a custom database table.

This would have multiple advantages:

• easy to store app passwords and backup codes in the same table
• super simple to lookup an app password
• no messy array to play with to invalidate a code
• no weird process to make sure that a key of a hash is unique (yeah it sounds weird)

The custom table should be something like this:

ID |user_id | key | type | count

If we go that way, though, it would make sense that the access log has its own custom table as well. The current access log has the following information:

• key (the app password hash key. Yeah, the weird thing)
• last_used
• ip
• user_agent
• method

It goes without saying that an upgrade routine will be necessary...

See https://wordpress.org/support/topic/bug-two-factor-authentication-enabled-on-every-password-change?replies=3

If this is still an issue it need to be fixed.

Hey,

I want to report a corner case. We have enforced 2FA for a select list of roles. But the user is able to log in without 2FA if,

1. The user has a capability directly assign to him in addition to a normal role like this a:2:{s:14:"capability_new";b:1;s:10:"subscriber";b:1;},
2. And wpga_active meta key is not set. We have a lot of cases where the 2FA is active but wpga_active is not set
3. And the capability comes before the role.

Thanks
Asif

We just enabled 2FA on a clients site. There are 10 administrator role users in addition to the client. He's set things to require 2FA for all administrators.

Only 3-4 got their 2FA setup before forcing use.

It'd be good to see which users have 2FA setup without having to click through to each user. Perhaps adding a column to /wp-admin/users.php with a icon or something to indicate they've setup 2FA?

Also, I didn't see documentation on this, but in our scenario I'm assuming those users without 2FA setup now can't login, correct? I think they should be allowed to login and then forced to setup 2FA upon login, but I don't think it works that way currently. Either way, it'd be userful to update the FAQ to explain thing for that scenario. (a few admins have 2FA setup, 2FA is forced, what happens with other admins)

Following all the latest changes, I believe it is time for a UI overhaul in order to improve the user experience.

By developing the plugin with many other plugins enabled (like e-commerce plugins), I realize that the important security settings that Authenticator adds are hard to find. Also, in addition to #28 and #26 having a brand new user dashboard dedicated to security would be a nice improvement.

Nowadays, there's no need for javascript for tooltips...

http://kushagragour.in/lab/hint/

At the moment the plugin only provides OTP using Google Authenticator. Because it would be cool to have other providers (YubiKey) and because I'd like to play with new APIs and systems, adding a providers management interface could be the next step.

Also, this would come in very handy for #21

There are quite a few things happening for a user that has 2FA enabled. At the moment, the code is mostly procedural, which works well, but having a user object could make things easier. It would also give a clearer overview of the user meta data and make it easier to retrieve pieces of information.

Hi,

is there any way, to change the expiration time of an access token?

Many Thanks in adcance,
Lars

As suggested in a thread on WP.org, an app password feature could be useful, especially for use with blog editing softwares such as Blogsy or Microsoft Writer.

App passwords should be created on a per user basis and appear in the user profile page. Passwords should be easily revokable and in order to ensure security a minimum of logging should be done on app passwords (last used and from where).

Add a direct link to the Settings page + Eventually add a WordPress notification "Google Authenticator is not configured. Click here to set it up"

Right now, if a user ignores the 2FA requirement until the login timeout is reached, they are locked out entirely and unable to log in.

Instead, if they log in successfully, they should instead be told that they MUST generate a code to log-in. This would probably require some sort of check that forces them to a generation page on every action, to make sure they didn't "deep-link" to somewhere in the admin interface to get around the login check (as they'd technically be logged-in correctly).

The secret key used to generate the QR code can't easily be copied to be saved in a secure location. Change the input disable.

Is there any support for multi-site Wordpress installs? After installing the plugin I got no options to configure any settings.

Because one of my goals is to add more providers, the name "WP Google Authenticator" won't be very accurate anymore. Actually, it is already not very accurate: I am using Authy to manage my TOTPs, and not GA.

Related to #22

So, after enabling this plugin network-wide on a multisite installation, I ran into several issues.

The first was that the TOTP field wasn't being added to the login page. From what I could tell, this was because wpga_options hadn't been propagated to the child blogs. This resulted in a request to please fill in my TOTP even though it was impossible to do so.

I was able to correct this by copying over the serialized data from the main blog to each of the options tables for the children blogs.

However! While this solved the problem of the login page not appearing on the child blogs, this did not solve the problem of being told I need to provide my TOTP on every login. :(

I wonder if the issue is that I have a TOTP on the main blog, but it isn't propagated to the child blogs either?

Update the library to the latest version.

Update textdomain to enable WordPress.org localization system (GlotPress). See #26 for prerequisites.

When a user set his personnal secret, the login count should be reset.

Add option for the admin to empty the list of used one time passwords.

Allow admins to force the use of 2FA for specific roles only (and not all users without distinction as it is now).

A checkbox list would let the admin check the roles that needs to use 2FA. This could be useful in order to enforce security for users with advanced permissions and not bother users with little permissions.

The current activation workflow is based on one principle that might have to be revised.

At the moment, 2FA activation and secret key generation are two different actions. This is to allow the user to deactivate 2FA without having to reset his secret key (hence no need to update the site in the TOTP app).

However, this makes the activation more complex for what I believe is a small benefit (if really it is a benefit).

With #17 it makes even less sense as the secret key will probably be removed from the user edit screen.

UX Issue

The current workflow also introduces what I think is a major UX problem. If the user enables 2FA but, for some reason, forgets to add the site to his TOTP app, there is no warning of any kind. The user can very easily end up being locked out of the site because (s)he doesn't have the TOTP.

For complete TOTP activation, the user should be asked to input his TOTP (like it is done in many web apps).

Proposed Workflow

Display only the activate button. Once clicked, the secret key is generated and saved via Ajax. The QR code is then immediately displayed and the user is prompted to input his TOTP.

The secret will be saved in a "temporary" meta (for instance wpga_secret_tmp). The QR code and TOTP prompt will always be displayed when this meta is present. Only when the user enters his TOTP, the temporary meta is deleted and the secret is saved in the final meta entry. This will avoid changing the parts where the secret is accessed.

Following a feature request on Facebook, it could be a good idea to check for the cookie before asking for TOTP.

The TOTP check is hooked on wp_authenticate_user (through wp_authenticate_username_password ) which has priority 20, while wp_authenticate_cookie, on the same hook, has priority 30. This means that an error is returned because of the TOTP before the cookie is check.

An easy solution would be to manually check for wp_authenticate_cookie within our auth function.

Generate X password that can be used if user can't generate a TOTP.

Some users have been in a situation where they were unable to get the OTP from their phone or there was a time sync issue preventing them to login using the OTP.

For those reasons it would be a good idea to have a fallback where an OTP could be sent by e-mail upon user request. The OTP would obviously have a longer lifetime.

The questions that remains though are:

• Should this be enabled by default (I believe it should)
• Should admins be able to toggle this on and off
  • How should this be toggled? Option? Constant?

As suggested by MJP, the auth code could possibly be moved to a second step. It would make things clearer for users who are not using the 2FA.

The secret key should not be displayed in clear text (security reasons). Instead, it should be retrieved by either:

• Asking the user to re-enter his password and ask for confirmation that the current network is safe
• Sending an e-mail to the user