This is also not compatible with Duo Authentication Plugin as well.
I would argue that because this issue compromises any follow up screen authentication to the Logins for sites that it should be the responsibility of this plugin owner as opposed to others, as it seems that 1.2 has introduced quite a few issues with the hardening.
By replacing the following lines in the login-nocaptcha.php in the authenticate function from:
update_option(‘login_nocaptcha_working’, true);
return new WP_Error(‘denied’, __(‘Please check the ReCaptcha box.’,’login_nocaptcha’));
to the previous:
update_option(‘login_nocaptcha_working’, false);
update_option(‘login_nocaptcha_google_error’, ‘error’);
update_option(‘login_nocaptcha_error’, sprintf(__(‘Login NoCaptcha is not working. Please check your settings.’, ‘login_nocaptcha’), ‘options-general.php?page=login-recaptcha/admin.php’).’ ‘.__(‘There was no response from Google.’,’login_nocaptcha’) );
return $user; //no response from Google
I was able to get control back to my sites.
Hi @shadowxvii thanks for reporting this. Unfortunately, we do not have plans to support compatibility going forward with plugins that do not implement the standard WordPress approach to login forms (including the Azure AD SSO plugin you mention, and the Duo Authentication Plugin mentioned by @richardsaunders). That said, if you would like to submit a pull request for consideration, you can do so here: https://github.com/cyberscribe/login-recaptcha
We strongly discourage regressing the code, either via the approach @richardsaunders mentions above or by running any version prior to 1.2. This is because these prior versions are susceptible to automated attacks.
Wishing you the best of luck in finding a captcha solution to meet your unique requirements.
The regression I mentioned above is to allow users that are locked out and cannot remove Two Factor Authentication from production level environments the ability to access their sites again, as this essentially locks them out until they deactivate the plugin manually via database flags, manual file replacement, etc.
Ideally the captcha wouldn’t persist to additional screens that do not contain the actual login form, is there simply no plans to support plugins that require Two Factor Authentication or post login screen criteria of any kind?
I’ll be happy to use something else if this is the approach.
@richardsaunders the approach you mention will allow you to log in under versions later than 1.2 by bypassing the reCaptcha entirely when using Duo Authentication. An alternative way to disable the reCaptcha entirely is to remove the plugin directory from the filesystem, which will delete and deactivate it. They effectively come to the same thing.
The fundamental problem is that Duo Authentication and Azure AD SSO use the same back-end to process their login activity as standard WordPress forms. However, they implement their own custom, non-standard front-end forms for their login screens. This mis-match makes it a custom “special case” job, on a plugin-by-plugin basis, to display the reCaptcha on each custom front-end. That is is if doing so is even permitted by the other plugins; there are no guarantees that they have implemented appropriate hooks for modifying their custom forms if they are using a non-standard approach to generating those forms in the first place.
The alternative of disabling the reCaptcha on the back-end for sites running these plugins opens up those sites to automated attacks, since by “spoofing” the custom login form elements from the other plugins, bots could completely circumvent the reCaptcha check, and launch attacks agains the standard WordPress login back-end as though the reCaptcha did not exist.
I would of course be very curious to hear if you find a workaround that is both compatible and secure beyond the makers of these other plugins aligning to the standard WordPress authentication approach in both their front- and back-end implementations.
If I uncover such a method I will divulge it here.
@robertpeake I’m the author of the Azure AD SSO plugin. I’ve had a look at this plugin, and I see how the fact that the Azure AD SSO plugin filters authenticate is problematic for your plugin (and any plugin which is also filtering authenticate and requires user interaction).
What would you suggest that is the “standard WordPress authentication approach”?
Here’s what I’m considering:
- Instead of filtering
authenticate, hook into init (or perhaps something more specific to wp-login.php) for initiating the sign-in and processing the response.
- On successfully matching the signed-in user (according to Azure AD) to a WordPress user, use
wp_set_current_user(...) and wp_set_auth_cookie(...) to make it official in WordPress.
- Redirect on to the right place.
(If you have any reference for what the most correct approach is, I’d be delighted to read up on that.)
And, this is besides the point, but just so we’re all on the same page: the Azure AD SSO plugin itself doesn’t implement a custom form for login. It triggers a standard OpenID Connect sign-in request to Azure AD, and processes the response, matches up the authenticated user to a WordPress user, and makes the user “be signed in” in WordPress.
Hi @psignoret thanks for getting in touch.
What I mean by “standard” is implementing the action hook login_form on a user-submittable form that then posts against wp-login.php, where a script that adds input values using login_form can subsequently process them using the authenticate filter.
I’m not sure what you mean by “makes the user logged in”, but I assume it involves a POST action against wp-login.php at some stage, because that is where the reCaptcha plugin hooks into the authenticate filter, expects reCaptcha values, does not receive them from your POST action, and prevents the login. When it prevents the login, it returns a WP_Error object with a message that I assume your plugin is catching and displaying on the user-submittable form. (That is, I assume this is how @shadowxvii found out about it.)
The one quirk we have accommodated in 1.2.1 is the WooCommerce customer login form, which implements a woocommerce_login_form hook instead of the standard login_form hook. However, it follows identical principles in terms of behaviour (i.e. gives us a place to display the reCaptcha on the form that posts against wp-login.php), so it was fairly straightforward to implement this.
Do let me know if this makes sense, and if you see a way forward.
I think the main disconnect here is that what you describe is still very strongly tied to the idea of modifying, or somehow playing into, the existing username/password WordPress form.
Azure AD SSO (and other similar plugins) are for folks who want to (sometimes) skip the WordPress authentication process, delegating the process of authenticating the user to a separate system. This separate system (Azure AD, in this case) is not under the control of the customer, or the plugin, and that’s the whole point.
Ultimately, customers will fall into one of two categories:
- Skip the reCaptcha for users who signed in with Azure AD, and enforce the reCaptcha for users using forms-based sign-in.
- Enforce the reCaptcha in addition to either forms-based sign-in or and Azure AD sign-in.
I believe the majority of customers will prefer the former.
In any case, I’ll look into this some more (and have a look at what some other related plugins are doing in this situation), and propose something.
H @psignoret — it sounds to me like somehow your plugin is invoking the authenticate filter without going through the wp-login.php back-end. I did not think this was possible.
However, if this is the case, the following beta version of the code may help:
https://github.com/cyberscribe/login-recaptcha
Please could you test it and see if you can now log in using your own AD methods without the reCaptcha verification being triggered?
No, the plugin does go through wp-login.php. So your plugin is still getting invoked (and blocking the sign-in from completing).
I think it’s a fair expectation on your part, and on the part of others filtering authenticate, that the filter will be invoked during a forms-based sign-in. So, I’ve done a bit of re-factoring and moved my plugin’s logic to run earlier, during login_init.
If the user successfully signs in with Azure AD, the WordPress auth cookie gets set, and the user is redirected immediately on to where they should go (these steps of setting the cookie and redirecting were handled by Core when I used authenticate, so I had to re-write them in my plugin). This effectively avoids login-recaptcha ever getting an opportunity to block the sign-in. If, however, the user attempts to do regular forms-based sign in, my plugin does nothing and allows yours to do it’s thing.
I haven’t done a lot of testing yet, but I’ve pushed an experimental version of this to the experimental-no-authenticate branch of my plugin, in case anyone wants to test.
Hi Philippe,
Great that you are doing your custom authentication higher up in the call stack so as to avoid a call to the authenticate filter.
I have also refactored the authenticate filter function to check to see if we are being explicitly called from wp-login.php or not–and to pass through if not.
So, it may be that v1.2.2 (just released) of the plugin will work with the previous version of your code. Have you checked? (I don’t have an AD account to test your plugin myself.)
In any case, thanks for working on it. I’m sure @shadowxvii will be pleased.
That change doesn’t really help in this situation, because my plugin does run at wp-login.php.
Ah, OK. I see. Sorry, it’s late and I misread your previous post.
