Feature Request – Ask for code on second page

okay,
i guess it wouldn’t mess with the loginflow in the way it happens now, which would be more future-proof, but i wouldn’t really like it.

furthermore:
any plans of implementing something like a force mechanism (for example for different user levels or based on capabilities; example: users who have edit_them_options need to have google authenticator enabled)

If the login flow is going to be a problem, I imagine at some point the www.ads-software.com core will be updated to allow Google Authentication. Thinking about it – the AJAX solution would probably also suit the only request I wanted which was to be able to use the autologin from my password manager ??

well, google authenticator and autologin would never work, since you can’t store dynamically generated codes in your password manager (or can yours do that?).
and if you have an extension for your browser it could happen that it breaks the AJAX solution, because it loads before the javascript for the ajax would load.
then the 2nd page would be the only option

Ah, in WordPress.com – autologin takes me to the second page with the Google authenticator text box. But using this plugin it fails because the extra Google authenticator input needs to be filled.

I’m guessing that with the AJAX solution the Google Authenticator input would be similarly hidden until after the login submit.

Just wanted to put in another vote for this. This plugin is great and works exactly as advertised — no complaints whatsoever, thank you Henrik. But I occasionally worry about whether some users signing up to my site in order to get support get confused by the authenticator field that doesn’t apply to their account and don’t log in and ask questions when they need to. It’s also occurred to me that a second page is perhaps the only 100% reliable way to know who it should be shown to or not.

However, a couple of other possibilities come to mind that might address the issue via easy UI changes instead of difficult refactoring:

1. Address it with a UI textual hint. Instead of “Google Authenticator code” it could say “If you have enabled the optional Google Authenticator code, enter it below” or something along those lines.

2. Instead of showing the field, show a button that says “I have turned on Google Auth for this account” and clicking or tapping it exposes the field inline, along with a button that says “I don’t have a Google Auth code” that will hide it again. Just make sure that a user who needs auth but who hasn’t pressed the button gets a prompt that they need to press the button and enter their auth or it will lead to a lot of support requests from people who forgot they turned auth on.

Both of those approaches demonstrate to the casual user that it isn’t a requirement for their login unless they have turned it on themselves.

Here’s a diff of the changes I made for AJAX support. Even supports lack of javascript support. I think this works really well and suits the purpose well of only showing to those who need it.

--- google-authenticator (copy).php	2013-06-10 13:06:42.000000000 -0700
+++ google-authenticator.php	2013-06-10 13:54:21.000000000 -0700
@@ -61,8 +61,10 @@
     add_action( 'login_footer', array( $this, 'loginfooter' ) );
     add_filter( 'authenticate', array( $this, 'check_otp' ), 50, 3 );

-    if ( defined( 'DOING_AJAX' ) && DOING_AJAX )
+    if ( defined( 'DOING_AJAX' ) && DOING_AJAX ) {
         add_action( 'wp_ajax_GoogleAuthenticator_action', array( $this, 'ajax_callback' ) );
+        add_action( 'wp_ajax_nopriv_check_otp_action', array( $this, 'ajax_check_otp' ) );
+    }

     add_action( 'personal_options_update', array( $this, 'personal_options_update' ) );
     add_action( 'profile_personal_options', array( $this, 'profile_personal_options' ) );
@@ -139,7 +141,7 @@
  * Add verification code field to login form.
  */
 function loginform() {
-    echo "\t<p>\n";
+    echo "\t<p id=\"google-auth\">\n";
     echo "\t\t<label title=\"".__('If you don\'t have Google Authenticator enabled for your WordPress account, leave this field empty.','google-authenticator')."\">".__('Google Authenticator code','google-authenticator')."<span id=\"google-auth-info\"></span><br />\n";
     echo "\t\t<input type=\"text\" name=\"googleotp\" id=\"user_email\" class=\"input\" value=\"\" size=\"20\" /></label>\n";
     echo "\t</p>\n";
@@ -153,6 +155,29 @@
     echo "\ttry{\n";
     echo "\t\tdocument.getElementById('user_email').setAttribute('autocomplete','off');\n";
     echo "\t} catch(e){}\n";
+    echo "jQuery(function($) {
+            $('#google-auth').hide();
+            $('#user_login').on('blur', function() {
+                if ($(this).val() != '') {
+                    var data = {
+                        action: 'check_otp_action',
+                        user: $(this).val()
+                    };
+                    $.post(
+                        '", admin_url('admin-ajax.php'), "',
+                        data,
+                        function(response) {
+                            if (response == true) {
+                                $('#google-auth').slideDown();
+                            } else {
+                                $('#google-auth').slideUp();
+                            }
+                        },
+                        'json'
+                    );
+                }
+            });
+        });";
     echo "</script>\n";
 }

@@ -492,6 +517,17 @@
 	die();
 }

+/**
+ * AJAX Callback to determine if user should have OTP
+ */
+function ajax_check_otp() {
+	$user = get_user_by( 'login', $_POST['user'] );
+
+	// Does the user have the Google Authenticator enabled ?
+	echo json_encode(trim(get_user_option( 'googleauthenticator_enabled', $user->ID ) ) == 'enabled');
+    die();
+}
+
 } // end class

 $google_authenticator = new GoogleAuthenticator;

+1 for this, showing the input field to users who don’t have it enabled is confusing and prevents me from using the plugin on multi-user sites. We’re also considering using this on www.ads-software.com itself, but it will have to be on the second page or we’d get an insane amount of support requests because of it.

I think the AJAX approach is a bad idea because it leaks whether or not the user has 2FA enabled, which will help an attacker. Imagine if an attacker knows that a site has 3 administrator and know their usernames. He can simulate the AJAX call for each of them and then target the one that doesn’t have 2FA enabled.

I don’t think we should really worry about the feature breaking because of WordPress updates. WP is very good at maintaining backwards compatibility; usually the only times a plugin breaks is if the plugin is doing something the wrong way.

Using the actions in wp-login.php to inject an extra step into the login process isn’t exactly a supported use case, but it’s not that crazy either. I’ve built plugins for clients in the past that did similar things to this, and I can’t foresee any changes to Core that would break it.

In fact, that’s how we do it on WordPress.com; it’s just a plugin that hooks into wp_login, login_form_{action}, etc.

Henrik, I’d be happy to refresh Rouven’s code and turn it into a patch for this, if you’re open to it. What do you think?

@iandunn: I would love to help with that (if i can).
maybe that would be a start for me to contribute to WordPress (which i wanted to do for quite some time, but didn’t really know where to start^^)

Yeah, that’d be awesome ?? A good place to start would be to do an SVN checkout of the plugin’s trunk, apply your existing code to it, then create a patch that can easily be applied by others who want to test it out and contribute. Upload the patch somewhere and add a link to it here.

There’s also lots of resources available for contributing to WordPress itself. If you’re interested in Core, the Core Contributor Handbook is a great place to start. There are tons of other ways to get involved too, from working on the community websites (www.ads-software.com, WordCamp.org, WordPress.tv, etc), documentation, reviewing plugins and themes, translation, etc. Check out make.www.ads-software.com for more details.

There’s also the #wordpress-getinvolved channel on Freenode IRC if you’d like to chat with people about getting involved.

okay, did that and uploaded my patch
I’m pretty sure it doesn’t go with the WordPress Coding Standards and I’m using the php Session, but that was mostly was just a quick’n’dirty solution which I wrote months ago.

Henrik hasn’t responded to this lately, so I went ahead and made a new plugin to do this instead of trying to get a patch in. It runs alongside Google Authenticator and modifies the login workflow so that only users with 2FA enabled are prompted.

It’s available at https://www.ads-software.com/plugins/google-authenticator-per-user-prompt/

I’m also offering a security reward if anyone can find a vulnerability in it.

If you have any questions or feedback, or run into any problems, please post them in the support forums for the new plugin.