Rethinking Captcha

CAPTCHA – Completely Automated Public Turing test to tell Computers and Humans Apart.

All current CAPTCHA implementations are doomed to fail due to the persistence of developers to place the onus on client side technologies for validation. Whether you show the answer to the challenge (albeit after making recognition difficult), or have users spin a photo until it is upright, you are still giving the end-point everything they need to pass the test.

It’s time to rethink CAPTCHA, and move the means of protection server side where it can not be manipulated.

Why Existing Methods Fail.

The use of distorted words worked for a while. It wasn’t long before those pesky enterprising spammers were able to defeat those using optical recognition software, and even do it in bulk as well as real-time. They also employed pools of employees to sit and solve these for eight hours a day… it’s hard to beat that.

It took some time before developers came up with using a level of interactivity to perform CAPTCHA tasks. Most used Flash for this, because they believe it to be a tamper-proof container in which to hide their method. The problem with this is that the container simply sets a flag of some sort, which is then sent off to the server. See the trend here?

It takes a second for one to capture the HTTP request after hitting the submit button. Some logic skills and a few more minutes and one can evaluate the difference between a successful and unsuccessful submission, and identify what exactly the container did to the post data in order to validate the post as legit.

The latest trend, jQuery/AJAX is NOT going to solve this problem either. Same issue at heart… end-point has everything they need to solve the problem and therefore, is script-able to bulk-post to the web site.

The end result is that if you are giving the keys to the end-point, and even masking them or placing them in a box… you are STILL giving them the keys!

Rethinking CAPTCHA from the Server Side.

Challenge / Response validation works and works well. Operating Systems, ATM devices and many other applications use the challenge/response technique. The problem with using that for CAPTCHA is that both the user and the web site need to know the credentials, meaning that the P for ‘Public’ in CAPTCHA has just become a closed system requiring registration… it is no longer just a public forum.

That being said, what if we take the user right out of the loop? Well okay that sounds absurd, it wouldn’t be a Turing Test if it were not actually taking the human into consideration would it? But if what this could be accomplished in such a way that the end-user does not experience the test at all, while actually performing the test?

This is all about testing for what a human WILL do, as opposed to what one COULD do.

This author proposes that the very act of perusing a website, locating a worthwhile article, reading said article, reviewing other comments and finally filling out their own comment can provide enough server side forensics required to fulfill a CAPTCHA.

Of course, there’s always a wrench thrown into the mix, what about drive-by visitors coming directly to the post and comment area from a source like Digg or other viable referrer? Well, you still have something because it is expected that the end-user at least read through the article before filling out the post form and then submitting it. Historical data helps with accuracy, but not required.

If you are interested in such a project and are located in Toronto, please let me know at kev at silicon-vision dot com or hit me up on Twitter.