Add the option to protect the login form

Does this also apply to the user login form in the login block as well? For some reason, I'm remembering that form had a different form ID than the normal user login form... but I could be mistaken.

The patch in #4 works as expected.

Hello !

I'm currently testing the patch. But could someone have an answer to #4 Salvis question ?

Thanks in advance ;)

Confirming patch works when honeypot is enabled on "User Login form" "User Login block". Yayaya. Thanks salvis and all :)

There is one bug though. Steps to reproduce:

1. Go to admin/config/content/honeypot
   1. Double check that "Protect all forms with Honeypot" is not checked
   2. Under "Honeypot Enabled Forms" section. Double check that "User Login form" and "User Login block" are not checked
   3. Click on "Save" button
2. Go back to admin/config/content/honeypot
   1. Under "Honeypot Enabled Forms" section. Double check that "User Login form" and "User Login block" are not checked
   2. Check "Protect all forms with Honeypot"
   3. Click on "Save" button
3. Test honeypot. Such as on the /user page. It's not added to "User Login form" and "User Login block" forms. Expected result is that it should. Because user checked "Protect all forms with Honeypot" option.

   Note: The above bug can only be reproduce in that specific order and exact steps. If user checked both "User Login form" and "User Login block" forms. Then save. Then user go back and checked "Honeypot Enabled Forms". Then save. That bug can't be reproduce.

If this is not a bug but by design feel really free to set this ticket back to "needs review". We're assuming that bug is related to the above comment 4.

Patch tested with

• Drupal 7.41
• Honeypot 7.x-1.x-dev 2015-Sep-03

Same here. Many of our websites also receive large number of spam bots and spammers on their user log-in forms and blocks.

About comment 4. I'll let geerlingguy or someone else answer that good question.

I suggest to remove 'user_login' and 'user_login_block' from the 'unprotected_forms'

If 'user_login' and 'user_login_block' where added to the 'unprotected_forms' because of a concern of user(s) or the admin locking themselves out of the website this is a very low risk because human would not willingly put anything into the hidden honeypot field. Robots will happily do that though, LOL ;)

One of the benefit of removing 'user_login' and 'user_login_block' from the 'unprotected_forms' is that it would significantly reduce the number of robot spammers accessing user's private information. Many site hide their user profile, email, contact information from anonymous users. But on users' request show that information to logged-in users. Many robot spammers who can get pass the log-in form abuse that. Remove 'user_login' and 'user_login_block' from the 'unprotected_forms' would reduce those abuses.

One of the benefit of removing 'user_login' and 'user_login_block' from the 'unprotected_forms' is that it would significantly reduce the number of robot spammers accessing user's private information.

If spammers are able to hack your site login form to bypass user login and view private user profile information, then that's something that Honeypot won't be able to help with.

The primary reason why those forms are in unprotected_forms is that they are filled out by password managers in < 1 second, so if Honeypot and timestamp protection were enabled on those forms, they would break common login behavior and make users frustrated at their inability to login.

Also, consider this—visit a few sites where you log in manually and check to see how long it takes to enter your credentials. If it's < 5 seconds, would you like to have to wait 15+ seconds to log into that site? Likely not. The user login form should not need spam prevention, because Drupal's built-in failed login flood limiting should take hold after 5 failed attempts, and if users have bad passwords that allow spammers to easily impersonate them, you should look into using Password Policy.

This module's number one goal, besides spam prevention, is to not punish the user. Therefore I'm amenable to adding an option to allow admins to explicitly protect the login form... but there's no way I'd protect it if someone checks the all forms checkbox, because for most sites I work on, that makes the user experience worse.

Honeypot is not a security-related module, just for spam prevention. User login form hacks are security-related and I've never seen a situation where spammers can use the login form to spam a site... See Login blocked after 5 failed login attempts for a discussion on flood control.

Thanks for your reply geerlingguy :) Make sense about the password managers. I agree.

To protect login forms against spam abuse. How about adding the following option? Honeypot time limit on "User Login form" and "User Login block" only.

Suggested user interface

I suggest that by default the seconds on "User Login form" and "User Login block" only be set to zero/0. So there would be no change in behavior for current users of honeypot. But if some users want to they could enable the spam protection for login forms with optional time in seconds.

In our case we would enable it and set it to zero. We have many large sites that badly need spam protection on login forms. As you know most spam robots would filled out the hidden honeypot field on login forms. While at the same time password managers could work.

Suggested user interface in text version

• Honeypot time limit on all enabled forms. Except "User Login form" and "User Login block".*
• Honeypot time limit on "User Login form" and "User Login block" only*
  • Useful if form is filled out by password managers. If unsure set to 0 to disable. Minimum time required before form should be considered entered by a human instead of a bot.
     

Would like to have for D8 version. Not selectable under config page. YAML export has login form disabled.

BTW none of the other modules that can help protect login forms this way are working at the moment against latest D8. Spamicide crashes on configuration attempt. The others don't have D8 yet. And the current D8 Image Captcha is not easily configurable and has very crude obfuscation compared with the D7 version.

Therefore honeypot for login form is high on my wish list.

Patch for 8.x-1.x version

I forgot to add variable to config install.

Last fix :)

+++ b/config/install/honeypot.settings.yml
@@ -1,5 +1,4 @@
-  - 'user_login_form'

Wouldn't we need to do a hook_update_N() hook to update the unprotected_forms config on existing sites? (And to add the new default for form_settings)?

Hello,

The current 7.x version does not seem to have the option to protect login forms.
Does this require the patch to work on 7.x?

Thanks!

@serenitystocks - Yes, you would need the patch. I'm still leery of adding login form support because of the issues stated earlier in this thread, but as a non-default, it may be supported soon.

Updating the patch with the latest one.

Updated patch for 7.x

I think 7 comes when 8 is fixed.

I can confirm that the D7 patch posted by Vijay works in my local Drupal sites. Anyone ese can review this to vouch for this implementation?

Due to changes on the contributed module development version, I am updating the patch files for D8 on this issue to be compatible with the latest changes.

I think captcha also offers this option fwiw. I also agree it should default to not be enabled for login forms, but having it as an easy to enable option would be nice.

1. +++ b/config/install/honeypot.settings.yml
   @@ -1,5 +1,4 @@
   -  - 'user_login_form'
   

   This needs an upgrade path for existing sites. The upgrade path should set the default value of form_settings user_pass to false if it was before included on the unprotected_forms array. Right now on installation it is set to false on form_settings, but people could've removed it from the unprotected_forms and then this needs to be updated if I'm reading this correctly.

2. +++ b/src/Controller/HoneypotSettingsController.php
   @@ -183,6 +183,13 @@ class HoneypotSettingsController extends ConfigFormBase {
   +      '#default_value' => $this->getFormSettingsValue($form_settings, 'user_login_form'),
   

   I believe the form_id is user_pass

New features need to be put into the current branch first, which is 2.0.x.

(delete comment)
do not use this patch

do not use this patch

If you have a distribution like Social, the form Id for the user/login page might be different:
id="social-user-login-form"

How would one manually test this?

At a minimum, we need test cases for this. HoneypotFormTest already explicitly tests that the user_login_form is not protected, so that test should be expanded to also toggle the protection then test that it becomes protected. That will ensure the feature continues to work properly.

You can see from the test result that HoneypotFormTest actually fails with this patch, because what you have done is to change the default for that form from unprotected to protected. That should not be done, as mentioned above - the default should remain as unprotected. That way HoneypotFormTest will continue to work and can be expanded to cover turning on the option to protect that form.

Also, + '#title' => t('User Login form'), needs to use $this->t().