Comment by ejames | Hacker News Reader

Comment by ejames | Hacker News Reader

Since several commenters have been asking for an explanation of honeypots and timestamps, here's a link[1] I happened to run across just recently and a quick explanation.

- Honeypots: Add a field to your form that is styled to be invisible to normal human users, such as being located off the screen, sized to 1 pixel, or placed behind/under images on the page. Bots examine a page through HTML rather than through eyesight and will not distinguish these fields. Reject submissions which have entered text in the honeypot fields. - Timestamps: Some spambots operate by 'playback' - a human fills the form out correctly once, then copy-and-pastes the form output into a script that replaces the comment text/etc. with desired spam links. Place a hidden field in your form that contains a timestamp (possibly hashed or combined with other form output). Reject submissions which contain a timestamp far in the past, indicating a bot which is 'playing back' an old submission.

The idea with defeating spam is not to be 100% accurate with unbeatable security, since no matter your system, a bot tailored to your site can defeat it. However, putting several simple techniques together can defeat general-purpose bots that shotgun spam across many sites. This reduces spam to levels that are manageable by hand.

[1]http://nedbatchelder.com/text/stopbots.html

A point made in the comments of the post is that blind users using screenreaders may notice and interact with the honeypot fields.

For this reason, I always add some brief text explaining that the field is there to detect spam and must be left blank.

I'm sure blind readers would prefer this approach to a CAPTCHA.

This is easily solved by text (again hidden moved off-screen for the normal user with CSS enabled).

"Thank you for filling out our form. Press <hotkey> to submit the form or <hotkey> to review."

"If you are not a real person, input your state now. Otherwise press <hotkey> to skip State : <input field>

That kind of text will still confuse the majority of Web users. It's the kind of thing my mom or wife would show to me and say, "So am I supposed to put my state in? Why do they have it there if I'm not supposed to fill it in?"

Are your mom and your wife blind?

It was a valid question - the GP was talking about blind users, and then some guy who didn't even read the discussion properly comes waltzing in with a non sequitur about his mom.

roel_v makes a valid point - the majority of web users will not see this text. The whole point is that it's hidden and will only be 'seen' by people using screen readers. The text could easily be changed to "To reduce spam we have included this extra field. If you are a human, please leave it blank."

Another form of timestamp analysis is to detect submissions that happen too quickly. A spammer's signup script is likely to fill out the form and submit it nearly instantly. Of course a spammer could beat this by waiting a small randomized amount of time, but that makes spam signups more expensive and might also deter them.

Many automated form fillers for normal people, such as LastPass or even FireFox's form fillers will fill out the submission forms and submit them quickly as well. Perhaps not as quickly as an automated script, but worth looking out for.

Well, that's for login. For registration it is usually not that fast.

This is a good method... especially if you look at it over the course of more than one page. If you have a multi-page signup funnel, you can watch the time it takes someone to get from the first form to the last.

A very rudimentary defense at best - any spammer or scraper worth their salt is randomizing their timing. Better yet, have timings derived from real users. For a dedicated attack (or even a category-specific attack like forum signups) timing would solve little.

I have traditionally used honeypot fields in this manner. Recently, however, I have noticed some false positives because of autofill features in browsers (especially Chrome). To work around this, I would add to the above that it may be useful to remove the field with the submit event on the form and then test for it's presence on the backend. Alternatively, just use the timestamp approach.

Much appreciated especially for the link provided. Quite helpful. When thinking about it, for a user registration (I don't have comments) this seems pretty reasonable. Combined with a few fun tricks on the input fields this should be sufficient enough, especially due to other mechanisms in my site. One less captcha on the web is only better :)

Reply on news.ycombinator.com