Honeypot Captchas for Rails
A while ago, I read a few articles on the technique of honeypot captchas and thought it was a pretty simple, but interesting, technique.
Essentially, with honeypot captchas you add fields into public facing forms that you expect to not be filled in, then you hide them through CSS (or other means). Since spam bots don’t usually apply CSS styles, the fields are visible to them, yet styled away for normal users. And we all know how spam bots love to fill in whatever fields they find… When the form is submitted, you simply check for these honeypot captcha fields to have values. If they do, then you stop processing the request and return as if everything completed a-okay.
I used this technique on a site several years ago and meant to package it into a gem. This weekend, I finally checked that off my todo list! Now, I’d like your feedback on whether this is useful and what I can do to make it better. Feel free to fork the repository and mess with the code. If you add a feature, please send me a pull request. Thanks!
You can find the repository here: Honeypot Captcha on Github.
References
More of my rantings
- Ruby on Rails Testing – flash.now gotcha
- Rails link_to and HTML options
- Ruby on Rails Resources for Newbies
These might also interest you
- Five Tips for Overcoming Burnout (Brainfuel)
- Stop Working for the Man (Brainfuel)
- Uncommon Uses for PowerPoint (Tomas Carrillo)
That's a pretty cool idea.
But I’m a bit concerned about accessibility and semantics. What experience do users with screen readers have? What will the form look like with CSS disabled?
April 12th, 2010 at 11:31 pmI would also recommend generating a random nonce string, storing it in a session variable and a hidden field in the form and comparing them on post submit. This is effective at blocking ANYONE that isn't posting the form from your site. The nonce should be generated per page load and per user and destroyed after validation. Combine that with your hidden-by-css-input captcha and some content filtering a'la Akismet, and you'll have some pretty air-tight, anti-comment-spam protection
April 13th, 2010 at 12:20 amI think that's a very valid point. Currently, their experience will be pretty poor. What do you think would make it better? e.g., adding a label to each field with instructions to not fill it out
April 13th, 2010 at 1:29 amVery cool stuff Mr. Miller! One more step in the war against the machines.
April 13th, 2010 at 4:06 amYes. I think explicit "Ignore this!" instructions would be very important.
I also think with certain technologies (ARIA maybe?) you can make screen readers explicitly ignore these fields. JavaScript could be used to remove the fields altogether, which I think would help assistive devices as well as the "no CSS but JS" scenario
April 14th, 2010 at 4:46 amDoesn't Rails already do this?
April 14th, 2010 at 4:47 amI added this to version 0.0.2 of the gem. I turned the honeypot_fields method into a Hash of field name/label text pairs. Theoretically, you should be able to override that method with your own Hash if you wanted more fields, different names, different label values, etc.
Check it out and let me know what you think.
June 14th, 2010 at 11:17 am