During work on a security module I have run into the question of whether or not I should use a CAPTCHA technique on user registration or if an alternative should be employed.

CAPTCHA’s in my mind are quite frankly annoying, like many other web users I have run into my fair share of those that either just don’t work or are very hard to read/interpret. Because of this I felt that some research into how good they actually are at preventing or reducing spam and automated bots from registering was needed.

A quick google for “CAPTCHA disability” returns an interesting article on the W3C [http://www.w3.org/TR/turingtest/]. I draw your attention to the final two paragraphs of the conclusion:

The widespread use of CAPTCHA in low-volume, low-resource sites, on the other hand, is unnecessarily damaging to the experience of users with disabilities. An explicitly inaccessible access control mechanism should not be promoted as a solution, especially when other systems exist that are not only more accessible, but may be more effective, as well. It is strongly recommended that smaller sites adopt spam filtering and/or heuristic checks in place of CAPTCHA.

Lastly, new approaches focusing on using exclusively visual or auditory means for access control, such as the “PIN Guard” mentioned above, should be scrapped until a reliable method exists for users who cannot access them to authenticate themselves. A short-term security benefit is not worth threatening a person’s autonomy by denying them access to such important data as their finances.

OK, So given that what I am working on is supposed to emulate a small e-commerce website, I can take that on board and I agree. So the question becomes do you abandon this kind of check and “sort it out later”? Or are there other things you can do?

I found a a blog post by Slobodan Kovacevic in which two non-discriminatory approaches are explained, they are not a 100% guarantee against spammers but they can help reduce the impact.

The first one generates a unique hash string in the page session where the form to be protected is located when the GET request for the page is received. When the form is submitted the hash is validated and if they do not match the request is denied as it means that a direct POST request was sent. The idea is that anyone who wants to send the form data has to visit the page with the form first, it prevents automated form submissions over POST. As Kovacevic points out this does not prevent someone paying a human to process form submissions by hand but it does add an unobtrusive extra measure with a very small overhead.

The second idea is to use CSS (and maybe some JS as well) to place “bogus” form fields on the form using names that bots will commonly fill out. If any of these fields contain data when the form is submitted the request will be denied. Downsides to this approach are two fold; First if the user disables CSS or JavaScript (or is using technology which does not use either) the fields will be visible and can potentially cause confusion, two name fields for example. Secondly it feels a little, well “clunky” to me, generating extra HTML just to catch out spam bots? I could be wrong but I can’t help but wonder if that violates one of the unwritten laws of web design.

This is not a huge considderation in the grand scheme of things, but it does pose some interesting questions. If anyone has any ideas or comments on this, please let me know.