A Classic Captcha
It is probably not unreasonable to say that everybody who has ever used the Internet has come across a Captcha before, even if they did not know that is what it is called. Just to get everybody up to speed, a Captcha is an image of a word or random text that you have to type into a box to verify that you are a human.
Captchas on the web are a pain for visitors. As hackers and crackers become more sophisticated, Captchas need to become more difficult to break. If you regularly see Captchas that you cannot solve then you are not alone. It is not just people with physical or visual impairments that struggle with Captchas, what about people with javascript or images disabled? Or what about people using mobile phones?
So we know what the problems are with Captchas, but what are the alternatives?
Kitten Auth – Asking you to Recognise Images
Instead of having an image of some text that you type into a box, you will see a selection of pictures or photographs. You will be instructed to “click on the pig” or “choose the red flower.” So long as you follow this instruction correctly, the system will verify you as a human.
For
Against
This is often provided as an alternative to regular text Captchas. A user listens to a word or a string of letters that are spoken and types them into the box for verification.
For
Against
You add a short sentence with a missing word to your form and give your users a few options to choose from to fill in the gap.
For example you could use “I have a ______ car.” The options could be “red”, “house”, “monkey” and “spoon.” Only a human would be guaranteed of getting the answer right.
For
Against
This solution sounds technical but it is actually quite simple to implement. Many bots scan the source code of your page for form elements. They give all these elements a value depending on what the field name is. For example if you have a field name called “email,” it is not difficult for the bot to guess what type of data is required in that field.
If you introduce a dummy form field into your form and hide it with a style sheet, the bot will not know it is an invisible field and will insert a value into it. You will find it easier to trick the bot into filling in this field by calling it something like “Name” or “URL.” You can hide a form field by using the style attribute display:none;
On processing the form, any submissions that have a value for the hidden field can be regarded as submissions by a bot and investigated or discarded.
For
Against
Akismet Can Cleanup Your User Generated Content
In my opinion, the future of preventing spam is about analysing what is being posted. Spammers are using the form on your website in order to post their content and links on your website. The most common areas are blog comments, wikis and forums. Therefore it is useful to think about filtering these posts themselves rather than validating the form that was submitted.
Akismet is a system designed to do just this. It is produced by the people who created Wordpress and it analyses the content of what is posted to determine if it is likely to be spam. The system has analysed billions of messages and is highly effective. You do not need to store anything on your own server because Akismet handles eveything remotely.
Akismet is very popular on Wordpress blogs but can be integrated to analyse any user submitted content. It won’t stop bots from submitting registration forms, but you can still block any content that they might submit.
For
Against
Google’s Difficult Captchas
Despite the many problems associated with their use, Captchas are very prevalent on the web. This article is intended to make you think twice before you blindly drop in a Captcha. How many potential visitors (or even customers) are you going to lose by putting such a barrier in their way? You need to decide if the trade off is worth alienating a large group of potential visitors, or is a more intelligent solution available?
This is a very good article. Well done.
I am very much against all forms of CAPTCHA for all the reasons you’ve highlighted above and more. They are anti-user, and they don’t really provide any real security, unless your idea of security means that all humans can be trusted whereas all machines/scripts can’t.
This is a problem I’ve struggled with for some time and haven’t really found the ultimate solution.
The best solution so far has been to request the browser to sign the request with a key-pair sent from the server. A browser can be “asked” to identify itself with an ajax request to obtain the server’s public key, and a one-time token can allow for it’s signature of the action – whatever it is: creating an account, posting a message, uploading files, clicking through all the pages of the site really fast (in script-like fashion), etc…