Allow to protect the user login form with a CAPTCHA (to prevent flood lock-outs caused by spambots)

You can protect the user registration as well as the user password request form through Mollom's administration pages.

However, it does not make sense to protect the user login form with Mollom, since only the user's login name could be checked.

Lastly, Mollom protects your site from spam and unwanted posts. It does not protect you from malicious attacks from hackers.

I'm re-opening this as a Feature Request against the latest version. I think the OP's request is valid and that Sun's evaluation isn't fully correct.

Twice I've been hit by spambots trying to login with admin credentials on my D7 sites. In both instances, the annoying result is that their failed attempts surpass the failed login max attempts number and I am locked out of my own site and required to truncate the flood table in order to login again. Adding a CAPTCHA to the login would alleviate this. On a site where the only users needing to log in are the occasional administrative users, this would be a great option/feature. For uniformity's sake, it would prevent having to implement a completely different CAPTCHA or other system in place for this one purpose when a redundant function is already available elsewhere on the site (Mollom).

With reference to Sun's analysis, fields are only really necessary if one has text analysis going on as an option. Otherwise, a CAPTCHA can just be set as default for the form. In addition, Mollom should be taking into account known spammer IP addresses, as well, even if it were to use some form of analysis.

Hm. Adjusting issue title accordingly.

I need to think about this. I'm not sure whether Mollom is the appropriate solution for that edge-case.

Understood. I'm just trying to think of ways to prevent this pretty annoying circumstance. It's pretty easy for someone to determine who the admin users are on certain sites that show "submitted by" information. Flooding those accounts, thus, is a simple task. Preventing it is not. The less common case would be a username collision from phishing expeditions/exploit probes.

I think that protecting the login form makes a lot of sense. At least having this option would be good.

The only reason I can think for mollom to not provide it is because of the load it would bring onto the mollom servers. Other than that I don't really understand the limitation.

Cheers

I agree, I also wanted to apply Mollom to the log-in form.

why install another CAPTCHA package when Mollom can already provide one?

I also agree, it would be great a way to stop bots bad login requests and not having to install another captcha module to do it.

I agree too.

I guess Mollom is a smart software to detect spam through scanning text and that's its business and USP, but it is also a CAPTCHA provider and it would be very useful if it also added user login form to its select list.

I also agree with markchitty point.

The ideal functionality for me would be if there was a failed login attempt, that it would then display the captcha. It's annoying to have a captcha every time you login, but it's reasonable to have one if you have a failed attempt. Does anybody know of a different captcha module that does this that I could use until this is available with mollom?

Maybe that's a bit too much functionality for a failed login. I login to lots of sites and I'm used to having to do a CAPTCHA on my first attempt. I just want them to do this and give them the easiest way to do it. I'm not sure if they will though :( Glad to see that there is a lot of interest for this :)

Hmm - well you can certainly add it via a custom script using the API, but I'm not opposed to adding it to the core module. My concern would be that we don't want people to use textual analysis with this as there is nothing really to analyze. I guess we'd need to add an option to the form info to indicate if the form is available for textual/captcha or both (and default to both) and then update the add form functionality to respect this. Happy to look at any submissions as I'm not sure I'll get to this in the near term.

Thanks eshta,

Yeah, I get all that. It's just like many products you adopt. You get it for one reason and end up using it for other reasons too. Mollom is a wonderful module, that just happens to use CAPTCHA to get it's job done. I want CAPTCHA on my site for all areas that may need it so I look to Mollom ... regardless of if that's Mollom's core use. It's right thought that Mollom should site to being Mollom and not a general CAPTCHA module. Although, it would be very nice if it could do both :)

I would encourage you to consider this line from #5:

In addition, Mollom should be taking into account known spammer IP addresses, as well, even if it were to use some form of analysis.

The idea being that it wouldn't just throw a CAPTCHA on the form. It would block a submission if it came from a known spammer IP address or domain or one of Mollom's other checks it does besides text analysis (although some usernames may trigger a known spammer trigger as well possibly). That way it doesn't necessarily interfere with your normal users but (tries to) challenge suspicious login attempts.

After all, that was the beauty of Mollom over adding a simple default CAPTCHA in the first place in many use-cases.

Hi there - Mollom already takes advantage of its knowledge of spammer reputations (including by IP) during CAPTCHA presentation. This happens even in CAPTCHA only mode - not just textual analysis.

@eshta - Great! That makes this request even easier, doesn't it?

[Sorry. Disregard this comment. Got 504 on previous submission, came back later, forgot what the tab was for, so I resubmitted.]

Here's a patch that adds the ability to protect the login form and limits the analysis options presented to CAPTCHA only. It's not complete as there are tests needed, etc., but I've set it to "Needs review" to allow the test bots as well as any non-bot who wants to give it a spin :-)

Ha - if I actually set the status properly.....

Haven't tested the patch yet, but just looking over it I have a couple questions.

Why the "limit_mode" functionality addition here? Seems like that should almost be a separate patch for a separate issue. It makes sense to have this functionality to limit to captcha on certain forms like the login form, but it doesn't seem like it's necessary for this issue as you could simply select captcha for the login form.

It appears that this patch will make it so that the captcha show up on the login form (assuming it's enabled on the login form) every time. Is there a way to make it show up only after a failed login attempt? Again, this may be out of the scope of this issue so maybe we just focus on adding the login form as an option and then create separate issues for this other functionality.

Hi @deggertsen - see #15 above regarding the limit idea and why it is included here. We really don't want to have login forms submitted via textual analysis. There is nothing meaningful we can analyze. You would likely see a lot of "unsure" results from Mollom which would then require a CAPTCHA. I can't imagine going from a login screen to the same login screen + captcha prior to actually logging in to be a good user experience.

As had been previously mentioned - anyone could add the login form to the list for validation via the api... it's simply being added here by default. The real meat at this point is adding as CAPTCHA only.

I think its very intriguing to extend this to some sort of specialized functionality where we can conditionally include Mollom if some form condition is met (like a failed login vs. a regular login).

Is there some such determination we can make in the code that could be used when defining the Mollom form hooks?

@eshta, good points and questions. I will try to look into the conditional inclusion of Mollom based on a failed login condition, but will probably post to another issue when I have time.

As for the patch, it looks good even though I haven't actually tested it yet. I'm reluctant to test without a failed login condition simply because that would be required for my use case.

The more I think about this - the more I feel that this is something that is best left to flood control measures rather than utilizing Mollom as a flood control prevention. Flood control would be far more effective than a CAPTCHA against bots and humans.

Part of the point is that Flood Control is working already and that's the problem. If a bot is trying to seek out admin users it has identified on the site via "submitted by" info and brute force attempts logins, real admins will be locked out by Flood Control.

If Mollom analyzes by IP address to present a CAPTCHA, then it reduces the likelihood of known spambots locking out admin users and forcing them to truncate flood tables.

This isn't a high priority request, but more for the occasional "what the hell? why can't I log in" situation, in my opinion. Just a nice thing to have.

Hello,

You can protect the user registration as well as the user password request form through Mollom's administration pages.

However, it does not make sense to protect the user login form with Mollom, since only the user's login name could be checked.

The reasoning behind protecting the login form would be the same as that for the password request form.

Since both forms don't actually save any data, it would seem mollom should protect both or neither.

Thank you for a great module!

Seems like this needs work for Drupal 8.

Please add an option to enable mollom captcha for user login form in drupal 8.