Posted by kwfinken on April 12, 2013 at 1:00pm
I have been looking for CAPTCHA alternatives. The audio alternatives are nearly as bad for the visually impaired as the pictures are (if you don't believe me, listen to one at http://www.google.com/recaptcha/learnmore). One alternative that seems to have good potential is the honeypot method (http://www.midwesternmac.com/blogs/jeff-geerling/introducing-honeypot-fo...). Does anyone have any experience with this type of method when used with screen readers or other alternative browsers? Any input is appreciated.
--
Kevin Finkenbinder
Web Developer/Programmer
Michigan State University Main Library
366 W. Circle Drive
East Lansing, MI 48824
finkenb2 (at) mail.lib.msu.edu
517-884-7352
Comments
Death to Captcha
Jared Smith at WebAIM describes CAPTCHA as a "Completely Automated Patience Test to Confuse the Hell out of your Audience" and I applaud your efforts to avoid it. We aren't using the Honey Pot module, but our server administrators have incorporated similar techniques.
Non graphics Captcha
I like simple mathematical questions
Simple mathematical questions
Simple mathematical questions are still problematic for those who cannot complete them.
Honey pot has been used extensively by us and works extremely well and is 100% accessible. The module is great and we're adding it to existing sites that we had previously added CAPTCHA to.
Honey Pot?
Do tell. I'm not a Drupal developer, but I support accessibility for a number of University initiatives, including several Drupal teams.
Honey Pot?
Do tell. I'm not a Drupal developer, but I support accessibility for a number of University initiatives, including several Drupal teams.
tmweiss, If you read the
tmweiss,
If you read the article at http://www.midwesternmac.com/blogs/jeff-geerling/introducing-honeypot-form-spam it will give you a better idea, but basically the system creates a hidden field that users don't see and screen readers ignore, but computerized spambots see the field and assume it needs filled. If the field has anything in it, then the form is declared as spam.
Honeypot
Seems too easy - i.e. eventually spammers will catch on. If the field is hidden, then spambots could just check for hidden attribute or style display:none etc. If it works now, then seems like it will stop working the more people use it.
Mathematical questions seem like a good idea, but eventually these can be coded for as well.
I hate captcha as much as the next person, and am not going to say they are a necessary evil, but would truly like to see data on how well these alternate methods are working. Actually, is there any real data on how well traditional visual/audio captchas are working? How would you even measure success: number of total submissions compared with known spam hits or something?
Just my two cents...
-- Rich
Honeypot is getting better
It is an endless cycle. As the spam protection gets better, the spammers get better, demanding stronger spam protection....
Ultimately when you can pay kids in Ukraine pennies to try to insert viagra ads into your site manually.. Any of these automated tests can fail if there's a human on the other end. Plus the technology to
Fortunately, there's movement on this front within the HoneyPot developer community to improve this:
http://drupal.org/node/1859090
I do think that the days where most CAPTCHA'S are really useful for stopping spammers might well be over:
http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html
http://www.wausita.com/captcha/
http://en.wikipedia.org/wiki/CAPTCHA#Circumvention
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Text-based captchas
I wrote a quick module that integrates the captcha module with the textcaptcha.com service. It has blocked tens of thousands of spam requests a month on our sites, and all users have said it's much better than the "text on acid" type of CAPTCHA:
http://drupal.org/project/textcaptcha
Mollom with Captcha disabled
Has anyone tried using Mollom with the CAPTCHA component disabled? There would still be the benefit of text analysis and Mollom's global filtering knowledge to stop the most egregious spam.
Mollom has a setting for what to do "When text analysis is unsure". Unselect "Show a CAPTCHA" and instead choose "Retain the post for manual moderation". Documentation here: http://www.drupalgardens.com/documentation/mollom/protect .
Has anyone tried that with any success?
www.pixotech.com
mollum without captcha
Horrendous experience. Literally hundreds of spamers. Now we're looking for a really air-tight captcha. thinking of getting rid of Mollum because it doesn't seem to do much.
It has been a while...
Brandon, I would have to look at our setup, but I was the admin for a fairly low-traffic site that was getting swamped with spam when I stepped in to help. The organization still tanked, but for completely different reasons. In the meantime, I was able to make the site totally spamproof. The key was the honeypot method and making all attempted registrations and the first few posts subject to moderation. I don't think I had to use Mollom--just the basic admin rules for creating accounts and permissions for posting seemed to do it. And it was completely accessible.
Unlike CAPTCHAs, honeypots force the bots to do more work and are completely invisible to actual people. Think about that--instead of my having to prove I'm a person, the bot has to prove it isn't a bot. That's as it should be.
We have been having trouble
We have been having trouble with SPAM (especially large volumes of user signups, even though there isn't a user profile on this site!), getting past Mollom - probably because of the lack of text fields. I switched off Mollom a couple of weeks ago, and have been using BOTCHA for all forms, which is a honeypot style module (and, as far as I can tell - accessible) that is pretty configurable. Even just using it on the defaults, submissions are down to less than 1 a day.
Yep, it was BOTCHA we used
Thanks for mentioning the name, Owen. That was our experience, too—BOTCHA reduced the number of spam registrations to such a low number that I could go in no more than once a week (I rarely went in that infrequently, but, still, that's all I would have needed to do) and delete them.
If I correctly recall the way Mollom works, you can set it to look for certain patterns in content or perhaps even in usernames. I thought about adding that to the mix—if it got through BOTCHA, run it against that filter in Mollom before validating the registration—but it seems to me that the nonprofit wound down before I got there. The bots that did get through all seemed to have one of only a few domains, usernames, or kinds of content, so Mollom probably could have weeded them out.
It's been a while, so I apologize for the foggy memory. But the bottom line is that BOTCHA gave miraculous results. The spam alone had this client convinced that they couldn't have a website, and activating BOTCHA changed their minds immediately. Great module!
Another Option: hashcash
In a discussion on DRUPAL4LIB, another suggested module was https://drupal.org/project/hashcash. Rather than require any user input, it requires the sending computer to compute a hash which takes about 1 second on a typical PC. Since this would significantly hinder spammers in their attempts to send high volumes, it tends to again knock out spam networks.
Any thoughts on it?
Three thoughts…
First, one second seems like a small time but can be enough additional delay to irritate, as in drive off, at least a few customers.
Second, it occurs to me that not everyone will have "a typical PC." Or connection speed. How would this affect, for example, smart phones? Tablets? People working through overburdened wifi connections?
Third, the concept behind it is comparable to some extent to that of CAPTCHAs. Whereas CAPTCHAs require your real customers to do more work, this approach requires them to suffer at least a little inconvenience—to wait while you size them up through this peephole in the door. Not bad to the same extent, but still in the bad direction. At least a bit.
I could be dissuaded from the second point, but I'm sure the first and third would hold up to further scrutiny.
It must be acknowledged that
It must be acknowledged that it's a clever idea!
re: Three thoughts...
1) I doubt if the one second delay will drive away customers as it takes place in the background after they hit submit. If you carefully choose which forms to apply this to (such as user registration forms), most people will just assume a common network glitch is slowing down the system.
2a) http://www.hashcash.org/benchmark/ shows that even on slow systems, the burden is not excessive. Based on what I have found, most cell phones operate at about the same speed as a desktop processor from about 10-12 year ago. This places them faster than a Pentium 3.
2b) network speed does not affect the system at all, the only added network burden is sending a few dozen bytes of data. Unless you are still on a 300bps modem, you will never notice a few dozen bytes and if you are on 300bps, then you are used to waiting for long periods of time.
3)Yes, this slightly moves the burden to "inconvenience" real users, but that is true of most forms of security. I am inconvenienced every time I go to the car and have to unlock the door before I can get out of the rain. But this certainly seems to be less intrusive than using traditional CAPTCHAs and more effective than Honeypot alone.
Well, you might be right.
Thanks for the data about the download speeds and so forth. I was wondering myself about the relative speed of cell phones. And as matters progress, their speeds will get faster still.
And customers will grow less patient. When I feel like something is taking forever, I will often pause to consider how much faster this delayed interaction is proceeding compared to the fastest possible such interaction just a few years earlier.
That said, you still might be right in saying that the customers will neither notice nor feel inconvenienced. And I would agree that this approach might work well in combination with a honeypot to keep spam down with minimal impact on real people.
Still, for developers considering new ideas, try to focus on ways to stop the bots without adding to the real customer's burden. That's the ideal.