wordpress / two-factor Goto Github PK

I added TOTP with my Yubikey slot 2 and the Yubico Authenticator successfully, but then realised I would likely need to use this on my chromebook and/or want to use slot 2 for my keepass database which requires OATH-HOTP method.

There is no option to delete config settings for a OTP once it is added to revert to a different Google Authenticator.

All of the settings appears to be hooked onto show_user_profile directly without priority. This can lead to an odd ordering on a profile with other plugins adding in features. Example with Yoast SEO installed:

https://cloudup.com/cNq7kO2kKcW

I'm happy to do a PR for this based on whatever approach is deemed best. My initial thought is have a intermediate function that all settings hook into, e.g.

function prefix_user_settings_display() {
do_action( 'show_user_security_settings' );
}

Then within each function that adds to the profile, swap out the add_action( 'edit_user_profile', array( __CLASS__, 'show_user_profile' ) ); with
add_action( 'show_user_security_settings', array( __CLASS__, 'show_user_profile' ) );

Thoughts?

It looks like XMLRPC uses authenticate() directly. The app password system works great with this, as it hooks into the authenticate filter. However, the rest of the plugin that ​_enforces_​ 2fa hooks into wp_login which fires in wp_signon() but NOT in authenicate(). Basically, you can sign in via XMLRPC with a user/pass OR a user/appPass. Both work and neither needs 2fa

FIDO U2F maps website URI (App ID) with the Security key which makes it fail on WordPress Multisite where each site would need to re-register the key to make it work.

I'm not sure if there is any solution since WordPress doesn't support any kind of SSO solution by default.

Two Factor Authentication not activated, you must specify authcode to ensure it is properly set up. Please re-scan the QR code and enter the code provided by your application.

Just started testing, set up my Yubikeys with the plugins and generated some single use passwords at home and was happy with it. Didn't enable email passwords or Google authenticator.

Come to work where the corporate browser support is Chrome 40, perplexed at first then log in with a single use and find out why. Ungh, thanks work.

I was previously using https://wordpress.org/plugins/yubikey-plugin/ which worked well, though a little inelegant in appearance and uses http for the api instead of https.

Suggestion: add a hook which would enable another plugin to extend with vendor specific methods such as Yubico API.

Looks like the personal_options_update filter isn't triggered when using the Enter key after entering the value in two-factor-totp-authcode input field.

We need to handle interim logins. When a login expires while a user is still on a wp-admin page, the heartbeat opens wp-login in an iframe. When it does, it adds an interim_login input that is passed along. We need to grab that, add it to our 2fa form to pass along, then handle it when we process that. Basically, it means that instead of redirecting at the end of a successful interim login, we need to load a page with a "success" message and let login_header add the proper classes that will trigger the modal (iframe) to be closed.

I'm working on this now, but wanted to log the issue.

After logging into via Jetpack's single sign-on button, we are redirected to http://localhost/wp-login.php?action=jetpack-sso&result=success... where we get a wp_die(), "Error, invalid response data."

PHP Notice: Undefined index: HTTP_HOST in /vagrant/www/wordpress-develop/src/wp-content/plugins/two-factor/providers/class.two-factor-fido-u2f.php on line 54
Notice: Undefined index: HTTP_HOST in /vagrant/www/wordpress-develop/src/wp-content/plugins/two-factor/providers/class.two-factor-fido-u2f.php on line 54

I get these every time I use wp-cli while two-factor is enabled.

Before merge consideration, we need to run the HTML output (settings UI, etc) through validation to ensure we're meeting specs or at least can justify any exceptions.

Would it be possible that I can specify the U2F Registration/Authentication Server?
That way, I can integrate U2F Mechanism of this plugin with my common server.

This will be particularly helpful in achieving single sign-on mechanism.
This can also be helpful for people who manage more than one Wordpress sites.

This plugin will not permit authentication (nothing happens) with a yubikey in version 4.6 of Wordpress after updating or with a clean install.

I feel like we could do SMS via email here. Rather simple, doesn't require a gateway, and I already have most carrier data from writing WP SMS. Thoughts?

https://github.com/georgestephanis/two-factor/search?utf8=%E2%9C%93&q=tel

I assume type="tel" has been used to force the number keyboard on mobile devices. It would be better use use type="text" inputmode="numeric", I think.

When it is set as primary, toggle the linked Enabled checkbox to on.

Most backup code providers will offer a print link that opens up a generic window suitable for printing codes.

Automattic (specifically WordPress.com VIP) dissuades the use of $_REQUEST in plugins and themes:

$_REQUEST should never be used because it is hard to track where the data is coming from (was it POST, or GET, or a cookie?), which makes reviewing the code more difficult. Additionally, it makes it easy to introduce sneaky and hard to find bugs, as any of the aforementioned locations can supply the data, which is hard to predict.

Much better to be explicit and use either $_POST or $_GET instead.

I made a pass at cleaning this up in #4, but at that point it was going to interfere with the work going on in the add/fallback-methods branch.

Notice: Undefined index: _two_factor_enabled_providers in /vagrant/wordpress/wp-content/plugins/two-factor/class.two-factor-core.php on line 515

This will avoid the awkwardness of remembering or copypasting a code when switching between apps on mobile.

Not as a full replacement for code, offer the code as well if they prefer it, but as a convenience thing.

We'll also want to confirm that the actual link clicker is coming from the same IP and User Agent that the initial first step of the login came through -- or maybe has a 'part1' cookie set or something -- just in case the email is exploited, we don't want someone quicker on the draw to click on the link and hijack the login.

The readme is woefully out of date. We should update it to better explain what we're doing and how folks can get involved.

When you attempt to login into the admin with Chrome and a non HTTPS URL you get a failed login attempt. However, there is no useful notification returned back to the user as to why the attempt failed. If the admin has not forced SSL login then this situation becomes possible. Even though it is an edge case, all exceptions and errors should be handled.

As well, you can't create keys in HTTP, and Failed is not expressive enough. The user should know why it failed.

RFC 4226 §4 requires a 128 bit secret key.

Using the Google Authenticator on iPhone 6 returns an error after scanning the secret barcode or entering the secret manually. Bumping the DEFAULT_KEY_BIT_SIZE in providers/class.two-factor-totp.php to 128 fixes the issue.

Users should be able to generate application passwords and delete existing application passwords without a page refresh -- just do it through admin-ajax.php

It should be added only to the U2F token login page and not the username/password page.

We need to close this security hole by forcing an admin lockout if attempting to login with an unsupported browser and FIDO U2F is the primary provider.

We need a logo and assets for the plugins banner.

Break out your Papyrus and Comic Sans, warm up the Rainbow Gradients and Drop Shadows, it's time.

I logged in as the admin user and tried to add a U2F YubiKey to another user (through the user management). When touching the YubiKey button, the message "Profile updated" appeared but the key was not added. I tried this 2 or 3 times, never worked.

I then logged in as that user directly and adding the key worked.

Can someone reproduce this? :)

I'm attempting to get Fido U2F working but I'm getting a "failed" message almost immediately when attempting to add a key. I've not, that I'm aware, having the same issues as others - not using https, not on multisite, etc. I'm using build 51 of Chrome on Mac.

This will avoid having to have each individual provider supply their own method for backup codes.

FIDO U2F can only be used with sites that have their login and admin available via HTTPS.

Web facets must use HTTPS, and either use a Top-level domain or have localhost as hostname.

see https://developers.yubico.com/U2F/App_ID.html

The plugin from the Wordpress database (vesion 0.1-dev-20151020) does not detect any FIDO keys. Clicking the button just instantly displays "Failed..."

Hi,

I am trying to register my yubikey neo with the plugin, but then clicking on "New" it an instant it changes to "Failed" without me doing anything.

I am running chrome 49, and verified on the yubico test site that the key can be used with this browser.

OS is Debian/unstable.

Thanks

Some login forms -- WooCommerce, for example -- use alternate login forms and don't submit to wp-login.php -- and so we don't have the normal wp-login.php functions like login_header() available.

I'd suggest we add in a check and if we're trying to authenticate without being on wp-login, we stash the redirect param and redirect to wp-login to handle the 2fa part, then redirect back to continue.

Quoting #116:

After changing the http to https, and unconditionally returning true in providers/class.two-factor-fido-u2f.php, function is_browser_support, I can use the yubikey also with firefox and the u2f addon: https://addons.mozilla.org/en-US/firefox/addon/u2f-support-add-on/

So it would be nice if this would be supported from the plugin out of the box.

providers/class.two-factor-fido-u2f.php has this line:

$app_url_parts = parse_url( home_url() );

This makes the appId used for U2F dependent on whatever URL is configured as base URL in Wordpress. In my case, that is the http variant of my blog and as a result, the appId gets set to http://domain.tld, causing U2F to fail. It would be better to construct the appId based on the URL I am currently accessing, or at least convert the http from the Wordpress base URL to https (as U2F will never work on HTTP).

For example, changing this line:
$app_url = sprintf( '%s://%s', $app_url_parts['scheme'], $app_url_parts['host'] );

to this:
$app_url = sprintf( 'https://%s', $app_url_parts['host'] );

makes U2F work on my blog, regardless of whether the base URL points to http or https (as long as the login page and the likes are being accessed via https of course).

The FIDO provider is adding something that is killing the ability to submit the user profile. Skimming Chrome's inspector, it looks like it is parsing the FIDO list table as ending the profile page's form element.

When updating and loading a QR code, let's do it without a page refresh if possible.

Currently we're using a Google API to generate the QR codes. Let's switch to an internal provider instead, either PHP or JS -- either from the https://github.com/kazuhikoarase/qrcode-generator repository should do just as well. It seems to be the standard (many other libraries already use it), and is MIT licensed. 👍

At the moment a user is only able to specify a primary authentication method. If the user now accesses the page using a unsupported system (for example U2F + vanilla Firefox) the plugin selects the first enabled method as fallback. As far as I can tell there is atm no way for the user to choose which method to use for fallback without disabling everything else. For me this automatically reverts to E-Mail while I would prefer Google Authenticator as a fallback (while keeping e-mail as a manual option).

Verbiage needs to be reviewed/added/changed for end-user clarification.

On it tonight.

Apparently it's a known issue that iOS doesn't like spaces in URLs. Since we put the site name in the URL, it needs to be encoded beforehand to handle any potential spaces

Just updated wordpress plugin to latest that just came out and now after entering the code I get:
You do not have sufficient permissions to access this page.

I updated plugin via the UI. How can i work around this until fixed?

Steps to reproduce:

1. Enable the plugin, go to your profile.
2. Select only the backup codes' method.
3. Save your changes.
4. The following error is displayed, although the method I picked isn't related to QR codes:

Having activated the Jetpack single sign-on and signing out, I was prompted to login in via WordPress.com or use my standard login. I chose the latter and selected my standard sign-in. However, where I should be able to enter my two factor code (via Google Authenticator) I was presented with a blank grey box which I couldn't input into. Instead I chose my backup method (email) and was able to gain entry that way.

Let me know if you need to know anything more about this.

Yep, apparently that's actually a thing. I spent hours tracking this down for an iThemes customer (we use the same pack function) only to find that they're on PHP 5.6.6, on 64bit architecture, but running 32bit PHP. PHP doesn't have a built in method for checking this, but we can use PHP_INT_SIZE. If it's 4 we're on 32bit, if it's 8 we're on 64bit. I used PHP_INT_SIZE >= 8 in the test, just because I dealing with 32 and 64 bit versions of PHP isn't enough fun and I hope they add a 128bit version some day.

The issue comes when you try to scan the QRCode with Authy or Authenticator on an iPhone. All the codes listed here scanned fine in Authy and Authenticator on Android. I don't have any iThings, but after enlisting some additional help (thanks Gerroald and Chris), here is what we have found:

I can't find a pattern. Here is a sample of tested secrets:

Works - 16
PCUAODJGC4
K5PKQLJXZE
ZFNI6CAJKY
AYXU3SFQUU
BKYW2YQFSI
VM6CKYH464
33OLV36CJE
L5LSRNRFP4
FDMKI76Z4I
XQN3RMLPJE
TDKB5C5PLM
BQLOVNSKXA
UGBGNXA4UM
GWYFA2PQTQ
JWIJS33WLY
OVG2YI472U

Doesn't Work - 34
MFHXO37YL7
D4ACQ2IEUP
CUYFNOXVQX
IWJCJDXQMN
56B67WMEMH
BXUBDQEJGD
5SQLGCU54C
4WCUJQF2GG
UGXEA3E5IP
74MP3SBVZR
AMDPNKC3GJ
UTO3CUD2UF
C5SEHK4MOH
YXJOI4F5NS
R54HXEKST5
UNVZ5NXHDL
AJAX3VKTET
3PE5CSCUXT
IY6MBR6XY2
3DCHEYW7ZW
EUPTLSCXMF
UBUZL6NAQB
UUJVMWC3OS
NSMYA4FBDX
DADVCUB65B
SIZBQM7VGZ
QB5I5ZYPHL
KX63TJE3RN
2XJZVWDSQ7
QSBJN4GTVZ
72FGY7TFIX
SIE3SSJBFF
OJL45N4G47
6RLC2YCT3S

These are all based on the 80bit secrets (10 digits) that we've been using. The spec actually says the secret should be at least 128bit (16 digits) but recommends 160bit (20 digits). So we tried 160bit:

Works - 4
LJSW6GLMYSXYMZ5P5BLQ
PVGGUSRCTJTJETY2KREQ
SPTLBWOLXY7P6W6I5SDA
WCCEPMA5JJBMNLQKJHAA

Doesn't Work - 24
UPMQN2TCMGYJVSLTMQ6V
Y53HYVZVMSN3UPRI54HH
UMOPXCHQV5HVGMD4XQQB
FGUAPWMRKAEXIVEPNNTL
6WXJUIM5Q3RDIG6TOKBC
7S2ICHPD5NEE3G6DDLNE
GB3FHZMOV4ALBE4ECD6W
X2TMQQKNUGKO4QG7BB6V
LZJFQO64EP4XY5TZ255R
HLI4RF43EPE3UWOBGH35
WRNLEK3K6AKQP2GUC56B
LLA4CQE5VCNNMCYEU3HD
I2FQDCDFU4A6HZPGYUG5
WTWAPV4W6VF37HYLJDEP
XFZ3DDYQDMWWSWSY5VWR
HJZFPTSRE554463WF2OR
UJ3YAREU3DT3RY6LVPXT
7FINEBDPUIGF7YYJED3H
KM5POSRVVIGYUJEO2LB4
BBNRK4XQRVN3UFXVWLOL
447A7RWFK73MNICGWXON
I4EPZZ7ZNQ7HV5NUBXTE
XJ7KQEOMFSC7DVAZ5NV7
BE7QZSLWQWMFAXJVFOVW

Then we tried 128bit secrets, and they all worked.

The problem is that it seems like 128bit secrets fixes the issue, but I don't know why. I hate implementing a "fix" and not knowing exactly what the problem is that it's fixing or why it fixes it.

Anyone with more iOS knowledge that could weigh in on this would be much appreciated.

Hi,

I'm using version 0.1-dev-2015-12-10 of the plugin with only U2F and backup codes being enabled. Whenever I try to save the settings, there is a warning at the top of the page saying: "Two Factor Authentication not activated, you must specify authcode to ensure it is properly set up. Please re-scan the QR code and enter the code provided by your application."

I do not have the Google Authenticator method enabled, so I guess this is a bug? Authentication via U2F is working fine.

Would it be possible to force users to enable 2fa on the first login?