I am adding spam protection to my personal php framework and I think honeypots are a great way to block spam. Unfortunately they weren’t invented yesterday and probably most bots do fetch CSS and can figure out whether the field is real or not. For example if I were designing a spam bot it would be highly intuitive for me to make my bot miss fields with display: none in their style attribute or fields that have relatively large style attributes such as width:0; height:0; border:none; background:none; position:absolute; cursor:defualt which is by the way what I’m currently using. Furthermore if all other fields lack a style attribute it’s highly possible that the only one that doesn’t is a honeypot.
In other words it seems to me that honey pots are not that difficult to spot. Can anyone with practice tell me which is the best way to hide a honeypot?
And JavaScript is not really an option because I’m building this, as I said, as part of a framework, so I can’t really hardcode some JS into a php function.
And finally, there’s no spam tag so I’m tagging this as security.
4
If you are building a web framework, this implies you can serve resources including HTML, CSS and JS files. If it has to be, you could even inline all resources into HTML. You can therefore use CSS- and JavaScript-based techniques to make it arbitrarily difficult to spam your form.
To each form field, you can apply a different class. Only one of these will be used to designate the honeypot, and you can use CSS to hide that input. This requires spam bots to include a complete CSS parser and to find out whether a given input will be visible. This is fairly non-trivial. Using inline style attributes does not afford similar protection, since using a regex such as /bdisplay:s*noneb/ could be used to detect them. Using CSS like this is the 20% effort, 80% success solution that’s actually worth doing.
You can easily improve this protection, e.g. by applying the necessary classes via JavaScript. This requires bots to run a JavaScript interpreter, but that turns out to be much easier than resolving CSS rules. You can obfuscate your CSS rules to require bots to implement CSS fully. Think about rules such as .the-next-one-is-spam + .field { display: none }. You can autogenerate class identifiers on each page load, so that hardcoding special rules for your site would be pointless for a bot. Or you could give up trying to throw together your own solution, and simply use an existing captcha provider.
The problem with honeypots is that on the one hand, they have to be indistinguishable from real input fields. On the other hand, there may be users with text-based browsers or users relying on assistive technologies. Other users might substitute their own style sheets. You can not rely on all your users to have JS and CSS enabled, and it would be nice if your site would still be usable despite that. Depending on your jurisdiction and type of project, you might be legally required to support users of assistive technologies.
Also, honeypots do not offer protection against human spammers which use real browsers. Honeypots can be one layer of defence, but on their own they cannot offer total protection. They are only useful to weed out the hordes of low-effort bots on the prowl for unsecured comment forms written with a 90’s script kiddie’s understanding of security.
1