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 ;-)
Comments
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
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).
Can you combine Mollom and Honeypot?
Yes, I do so on a few sites, and it's a potent 1-2 combo!
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?
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.
Yes, thanks for that. I have just read the https://drupal.org/node/2106455 issue and comments.
Are you using one anti-spam module per form, or both of the modules for all forms?
I usually use both for user registration and webforms, but only Honeypot for comment forms—unless the site is pretty high-traffic.
Noted.
And thanks for the clarification.
Tau
I just posted an article on my personal website about Preventing Form Spam, and included Honeypot as an example of a first-level spam prevention technique.
I will implement this, along httpbl, as a fallback. I hope that this will take care of the spammers. :) thanks for this module.
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.
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.
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.
Thanks for the affirmation!
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
The waiting time is only increased per-IP address, not per-user, so bots don't affect other anonymous users' experience.
Why aren't you using Honeypot for your own comments form here?
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 :)
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!
20 spam accounts blocked in 4 hours! Thanks so much!
great module. i am using it on my drupal site to fight spammers
Hello Jeff, I would like to use honeypot for spam prevention on the above site. In particular, the guestbook (Gaestebuch in German) gets loads of spam. I may be a bit naive, but could you please how to go about this? E.g., what form to I specify for protection? I have activated the honeypot module already. Regards from Salzburg
If you want to protect the Guestbook (http://www.rainermusik.at/guestbook), it looks like that page is using a normal comments form, so in Honeypot's configuration, you would enable honeypot for either all forms, or if not that, then just comment forms.
I'm using the spamacide module. I might consider using honeypot. I also set up a rule in drupal that sends an email to site admin when a new comment is posted. The rule adds the comment title and comment body in the message as well. This way, the admin can see the content of the comment to determine if it needs to be deleted or if its okay to keep. The admin doesn't even need to look at the site to determin that, saving time. It's not a high traffic site so it works well as intended.
I am afraid that current spambots have no trouble by-passing Honeybot. The hidden field is never used, and bots that are stopped by Honeypot the first time come back later and by-pass the time limit by using a simple delay.
Some bots have been customized to get past certain honeypot techniques, but it's still fairly effective; please check out this issue for more details and war stories dealing with targeted spammers: https://www.drupal.org/node/2646380
Nice innovation Jeff.
Keep up the great work!
As an update, Acquia has ceased support and maintenance for Mollom, and users are encouraged to disable the module although it was still effectively blocking spam from my Drupal 7 site up through July 2018 when I am now switching to Honeypot. I've heard of Honeypot for years and am looking forward to using it with Drupal 8 as am I upgrading. Thanks, Jeff, for the Drupal 8 port! You'll see comments elsewhere online about using Honeypot in addition to the AntiSpam module as a replacement for Mollom, but there is no Drupal 8 port underway for AntiSpam, so I'll be looking for a different alternative if I feel I need something in addition to Honeypot.
@couturier - I am currently using CleanTalk with Honeypot and it seems to work pretty well.
Hi,
This method is nicely blocking spam subscriptions on our Drupal site. Thank you.
Is there a documentation available to implement this method (combination) on native html forms implemented on non-Drupal sites?
Thank you,
Attila