[jackson71]

A couple of ways I've handled the spam situation in the past:

1. Base64-encode your form field names and decode them server-side prior to processing, or...

2. Create one-time use field names using md5 hashes of random numbers, map them to their true fields and store them in a session. Then process against those on the server side post-submit and clear the slate. (I used this method more often than not.)

3. Control the visibility of the honeypot field with CSS rather than "type=hidden".

Using #1 OR #2 in addition to #3 I've never had to use CAPTCHA nor human tests. A few paid spammers have come around from time to time, but since automated software isn't sophisticated enough to pick apart which field's which it either doesn't even try or it throws whatever it can at the fields, getting locked up in server-side validation.

[TomGullen]

Good points. In regards to CSS I think it's important to specify exactly what you mean though. I've seen this implemented dangerously where they simply position the form control off the wide (left:-4000px). This is vulnerable to browsers auto filling!

However hiding it completely with display:none should be safe and is what I think you mean.

In our case, just hiding it works fine. We can upgrade this to a CSS solution if we need to upgrade it though. The main point is if your doing something, you're ahead of the herd enough for spammers to generally leave you alone.

[jackson71]

On #3, you want to ensure that the CSS is externalized and the class name non-obvious.

The amount of additional processing power it'd take to surmount this (and the other methods) from a spammer's end at scale would be incredibly prohibitive, and that's kind of the point.