Introducing the Honeypot form spam protection module for Drupal

Now that I've released a Drupal 6 backport of what I originally wrote as a Drupal 7 module, I figured I would write a little bit in the way of introducing one of the simpler, and more user-friendly ways of controlling spam in Drupal (as opposed to other also-helpful methods, like Mollom, CAPTCHA, etc.).

I'd like to thank Flocknote for giving me the development time to work on this module, as we needed something like it for the new 'version 3' launch of www.flocknote.com.

The Honeypot Method

Honeypot is aptly named because, just like Pooh bear is drawn towards honey jars, spam bots are drawn towards form fields—especially form fields they think will give them the ability to link back to their own websites. So, the Honeypot method basically inserts a hidden form field to Drupal (or other) forms with a field name like 'homepage' (you can set it to whatever you want). End users don't see the field, so they don't fill it out. But spam bots (usually using prewritten scripts) do see the field (usually), and add something to it. The Honeypot module detects this and blocks the form submission if there's something in the field.

Additionally, the Honeypot module adds in a Timestamp-based deterrent. Usually, forms take at least a few seconds to fill out when a human is entering data into them—especially surveys, user registration forms, etc. Spam bots try to fill out as many forms as they can in as little time as possible, so they will often fill out a form within a couple seconds at most. The Honeypot module requires at least 5 seconds to pass (by default - you can adjust this too!) before a form can be submitted.

The Honeypot + Timestamp form protection method is a very good defense against spam bots, but not against actual humans who fill out forms for spammers (update: there are now some ways you can configure the module to deter 'real' spammers; see honeypot.api.php). If you start having serious spam problems, you might need to add in Mollom or another more intelligent spam prevention service to the mix. The greatest advantage of the Honeypot method is that the user is given no extra obstacles to completing a form. In my opinion, it's the most user-friendly way of preventing spam, even if it's not the most effective in every situation.

Other Niceties

You can also bypass the Honeypot protection for certain user roles—say, for instance, site administrators, who just might be able to fill out a form in less than 5 seconds—and you can set which forms on which Honeypot protection will be enabled. You can also tell Honeypot to protect all forms on the site. Finally, you can use honeypot protection in any of your own forms by simply including a little code snippet included on the module's project page.

The module is currently undergoing development, but is stable, and in use on a few Drupal 7 and Drupal 6 sites. Download Honeypot for Drupal 6 or Drupal 7 »

Does anyone want to make a neat little open-sourced graphic of a honey pot that I could use on the module's home page? I want to do one myself, but just don't have the time to do illustration much ;-)

Jeff Geerling is a Technical Architect at Acquia, owner of Midwestern Mac, LLC, and author of Ansible for DevOps. He is an active contributor in the Drupal community, and has primarily been a Mac user since the 1990s.

Comments

sfk's picture

Great module! Not use on live website yet, but very like me. I hate captcha, answer to stupid question on any form... Thank you! But why use on this site captcha?
happy end-re

Jeff Geerling's picture

Unfortunately, on this website (and on a few others I run), spam is such a problem that Honeypot isn't enough protection. Honeypot works great up to a point—once spammers start targeting a site (because it gets good Google PageRank, mostly), you have to start using stronger form protection (I'm using Mollom here).

Personal site: jeffgeerling.com.

Tau Lim's picture

Thanks for the response.

Anything to look out for if combining these two? Or is it safe to go ahead an install the two and let them co-exist independently?

Jeff Geerling's picture

I would just make sure you test all the important forms on your site (both as a logged-in and anonymous user, if you let anonymous users post forms), and make sure they're working normally. A few people have reported that the Honeypot time limit may not play nicely with Mollom on certain forms (see: https://drupal.org/node/2106455), but I haven't run into this issue myself.

Personal site: jeffgeerling.com.

Tau Lim's picture

Noted.

And thanks for the clarification.

Tau

Al's picture

Simple question: how do you show the honeypot field on the page such that it displays to spambots, but not to screenreaders? The only methods I can think of are visual, which would mean the field was read out to people using screenreaders (e.g. people who are blind or partially sighted) as if it was a regular field they should fill in.

Jeff Geerling's picture

Typically, screen readers won't announce elements that have display: none applied via CSS, and that's how the Honeypot module hides the field. Also, adding a description text like "don't fill out this field" can help.

Personal site: jeffgeerling.com.

David's picture

This module completely eliminated spam bots attempting to register on my site. Logs show more than 20 attempts per hour being effectively blocked. Now only real people are showing up for new accounts. Thanks for a creative solution.

David's picture

Jeff, it's nice to see someone of faith doing well. FYI my website your module is protecting is for a Christian non-profit designed to equip military lay volunteers to help others learn how to read the Bible and strengthen their faith. You can see it at mil.navlaborer.org.
Dave

Churris's picture

Hi Jeff, the problem that I see with the module is if my form accepts comments from anonymous users, if a bot hits the form previously a few times, this will force a real anonymous user to wait for for a long time. Is there a solution to this issue? (eg. do not increment the waiting time for anonymous users).

Thanks

Jeff Geerling's picture

That's a good question! I actually do have Honeypot on comments on Midwestern Mac, but this site has been the target of many human spam campaigns (I guess it has good enough pagerank), so I've also enabled Mollom on top of Honeypot's protections to do content analysis.

Sometimes you need a bazooka and a cannon at the same time to fend off spammers :)

Personal site: jeffgeerling.com.

daphne's picture

One of the big issues on the site I admin for is that all the spammers have started using 127.0.0.1 as their IP address; hence, we can no longer block IPs that trigger over-active user filters.

I wish there was a way to block an entire post submission that had a certain word in it, as the main problems we have are from a few sites who use 127.0.0.1 and link to a certain site. This site is always in their posts. If I could reject these submitted-for-approval posts with the certain web pages in them, I would cut down approval-required posts from five pages a day to one-half!

Add new comment