Another technique against spambots that I've used along the line of "hidden fields" is to have a textfield that should NOT contain anything at submission time.
You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there.
Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.
One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.
That's wasted effort. The bots are usually built by humans, and the humans can detect that and build the bot to ignore text fields with margin < -1000 or the unique name or something.
I think it depends on if you are trying to avoid automated attacks or targeted attacks. There seem to be a lot of bots scanning for vulnerable sites - this would potentially work for those.
If you get targeted specifically, then, yeah, the human in charge can figure it out in short order.
I agree. I think this method is a great idea and is much more foolproof:
"You could also use Honeypot Captcha approach: you can create a honeypot form field that should be left blank and then use CSS to hide it from human users, but not bots. When the form is submitted, you check to make sure the value of that form field is blank."
Fails the same test. I build what can be considered bots for a living, though they have nothing to do with spamming or otherwise shady reasons.
Part of the process in building the bot is to send exactly what a browser would send, and we do this by actually making the requests in a browser and viewing the raw request. If my browser doesn't send a honeypot captcha, neither does my bot.
Say you have a field hidden with a div on a low profile, minimum traffic site (100 visitors a week). It's incredibly unlikely and pretty dumb for a bot to be made specifically for that site -- in this case, how could a bot determine whether that field should contain a value or not?
I use honeypot fields, but you have to be really careful with them, and certainly do NOT just discard requests with the honeypot field filled, as the article suggests.
About 6 months ago, the new version of Chrome started auto-filling email addresses into my honeypot field, so it was a good thing I returned a friendly message (explaining that some auto form-fillers might cause this error, and needed to be temporarily disabled) rather than just assuming "bot".. but I still had some pissed-off people who had been trying to give me money and couldn't.
It's also worth noting that honeypot fields are only useful on a small site that is unlikely to be specifically targeted. A custom-tweaked bot can very easily bypass a honeypot field, of course.
You hide the textfield (margin: -10000px) and give it a name unique enough, that browsers with autofills won't have a record of a value ever entered there.
Spambots usually fill every fields, so if you see a value in the field when you process the registration, you know that it's highly likely that a non-human is registering. You now have the option of rejecting it, or accept it but put the account in a "monitor" queue.
One pitfall is that this scheme expects everyone registering to uses css. You can however give various hints to non-css users, to keep the textbox empty.