Show Captcha After X Unsuccessful Attempts

I was about to open a similar feature request, but I did a search first and ran across this issue. It would be nice to have an option similar to what Mollom does, where the capture only appears when triggered by certain bad behaviors. Wufoo recently rolled out similar functionality across their forms.

hi
i have same issue
how you solved
recaptcha also not working from second attempt on wards

please share with me

I haven't solved this. I haven't had time to attempt a feature addition for this mod. I'm hoping the maintainers like the idea and add it in.

I think this is a rather specialized use case and I think this would fit better in a small separate module than in the core CAPTCHA module.

I don't have the time nor resource to do this myself, but if someone else wants to do this, I'm willing to provide a helping/guiding hand. What should happen in short:

• hook into the user_login form with hook_form_alter on form_id 'user_login' and 'user_login_block'
• count the number of tries, I think you can user $form_state for your counter
• when above threshold, add a CAPTCHA element:
  <?php
$form['captcha'] = array(
  '#type' => 'captcha',
)
?>

I have the same problem. Subscribing...

I used the details soxofaan posted above to write a simple single function proof-of-concept module:

I'd like to expand the module to include an interface for adding forms, along with configurable settings for each form. Possible bad behavior triggers could include:

• missing token: if a user submits the form but fails to submit the hidden form token
• same IP: number of times a user from the same IP address can submit a particular form before triggering the captcha
• flood: x requests in y time causes the CAPTCHA to display (using flood_register_event)

Any other trigger or feature ideas?

subscribing....

I have the same need for the project that we are currently working on - we need to show captcha on login form after x login errors.

Based on #4 and #6 I have created captcha_after basic module with a couple of changes in proposed logic:

• I didn't use $form_state['storage']. I tried it and it simply didn't worked. Maybe the reason is that $form_state['storage'] should be used for multistep forms. For now module is storing counter data in session.
• Instead of adding captcha element after defined threshold, module will remove captcha element while counter is smaller then defined threshold. I think this approach is better and will allow tighter integration of captcha_after and captcha module. This will allow a user to define captcha for forms like he is used to and then he can define threshold only for forms that he wants.

Current module is tested on our dev site and it is working ok for our use case. Note that this is very basic version and it has next limitations:

• Currently it is working only for register, login and login_block forms.
• You can choose for which form you want to turn on captcha_after.
• You can only define threshold globally for all forms.

Before doing some more coding and trying to implement some other triggers or some other feature I would like that others check proposed solution.

Thanks for sharing module with us.
I have installed this module but after that there is no captcha in login block and every where.

Subscribing for now. Will post feedback when get time to test this. This is very important feature for mitigating brute force attacks and automated bot activity.

@mnp thx for testing. I don't know exactly what is a problem you have, if you can share some more info about potential bug that would be nice so I can reproduce it and fix it. Bugs are very possible because I didnt have time to test module properly.
For now captcha_after is only changing user_register, user_login and user_login_block form and is not working with others captcha enabled forms. On that 3 forms catcha will be shown when user reach captcha_after_threshold limit (default is 3) - that means if you have captcha enabled login form and if user enters bad login data 3 times in the next reload captcha will be added to login form.

@crea yes I agree very important feature, and I was supprised first when find out that it was missing. And this is also important usability feature - because we can remove captcha field for real users.
Actually I already decided to continue to develop this module. First thing that I will add is better integration with captcha - so user can decide for which captcha enabled forms he wants to add captcha_after and define threshold per form. After that I am open to feature requests.

I recommend splitting it to 2 parts:
1) "Detector". this is where different "suspicious activity" criteria are implemented as plugins and thresholds are configured. "X failed login attempts" would be just one plugin.
2) "Action" part, where different actions are possible as plug-ins. Captcha would be one of such plugins.

Having such separated architecture will allow much more flexible configurations. Admin may want to have both different criteria for detecting bot activity (mass messaging, too fast fetching of pages etc) and different actions for reacting on such activity (logging, blacklisting user, whitelisting user after successful captcha etc).
So having such flexible solution will help in different areas: prevention of bruteforce attacks, detecting of mass mailing, mass private messaging, mass form submission, detecting DDOS botnet members (both with whitelist and blacklist).

I think that would make sense to implement on top of Rules module, cause what I describe is actually Event-Condition-Action system that Rules implements.

The captcha_after module works OK for me.
Thanks a lot pivica!!!!!

@lorcon i am glad it works for you :)

Tomorrow I will be visiting Vienna drupalcamp, after that (next week) I am planning to do little more coding and upload new version.

@crea using Rules modules, sure if it will do the job. Many nice ideas you have but all this will require lots of planing and time to implement. Maybe better idea is to first finish some basic version of this module and put it on drupal.org, after that we can create new branch with rules support.

One other trigger that could be useful is a "honeypot" field. The idea would be to add a field on the form, but hide it using CSS. If the field comes back with a value, it's likely that the submission is spam and should trigger the CAPTCHA display.

@Matt in #15:

If the field comes back with a value, it's likely that the submission is spam ...

If a honeypot field comes back with a value it is certain* that it comes from a spam bot, so why giving it a second chance? Just block the submission, no mercy (being a CAPTCHA).

* The assumption is here that all humans use a CSS capable browser (or at least one that supports hiding with CSS). An important exception are screen readers for blind people, as far as I know. A quick google query indicated however that it is still possible to hide stuff for screen readers.