Captcha thoughts

So I have just had to implement a captcha protecting a email function of a site I am working on.  I'm a bit disillusioned by the options I found.  After some research I discovered pretty much what I suspected - captcha is getting beat. The first gen captchas were the equivalent of the Army private shouting "Halt who goes there, Friend or Foe?"  Well duh, what would you answer?  If you are either Friend or Foe you are going to answer the same thing. OCR techniques, session hijacking, and mechanical turks are quickly making child's play of breaking these first generation captchas.  For the purpose of this entry I am going to add my additional requirement that I need a captcha that can be used internationally.  This means I can't just spit out the same English characters for a user in Greece.  Their keyboard just won't be able to allow them to enter the proper characters.

So what to do?  There are other alternatives.  Kitten auth lets you select all the kittens.  Carnegie Mellon the originators of captcha are trying some new techniques.  Most have to do with image identification.  Many will not fulfill the international requirement I have. I believe there has to be a way to enhance the current captcha techniques and still make the captcha easy for a human to fulfill and hard for a script to complete. 

Let's break the capthca down into it's parts.  The first part is the Directive.  The directive tells the user what to do.  The first gen Captcha had a pretty stupid directive, (type all the characters). The next level of Captcha will need to ask the user to do a bit more.

The second part of the captcha is set of data that the user must apply the directive to.

The last part of the captcha is a location for the user to enter and submit the response.

So let's noodle on this a bit.  Most characters are out because they are language specific.  The only characters that seem to cross cultural lines are... numbers. Hmmm... So we need to create a captcha that allows users to input numbers as the answer to our directive.

The problem goes deeper than just challenging the user to input a distorted string of numbers.  Taking a queue from the web security world lets apply the concept of defense in depth.  Let's force the cracking script to do as much work as possible for the following tasks:

• Understanding the directive.
• Understanding the datasets for the response.
• Entering and sending the proper response.

Lets take a look at how each of these can be used to confuse a captcha script.

Understanding the directive

The 1st gen captcha has an unchanging and unimaginative directive... "What are these letters, please enter them"  What if our new captcha asks better, smarter questions?  This is another variable that can be inserted to cause the script to use more cycles.  If you are prompted "Please type the second, 5th and 3rd numbers from the picture below".  This is a fairly simple sentence for a human to understand, yet for a script it will have to do some guessing to get it right.  Why not render the question as a picture as well?  Distort the words, drop letters and use different colors would allow a multitude of possibilities for the captcha script to choke down before even attempting to evaluate the list of responses.  Many different classes of directive questions could be created about a grouping of numbers.  For instance:

• Enter the striped characters in order from right to left
• Please type the second, 5th and 6th numbers starting from the right..
• What two numbers are inside other numbers?
• List all numbers that touch the striped number
• etc.

Many different directives that are thoroughly difficult for a script to figure out can be presented. 

Understanding the choices for the response

It could also be possible show two or three sets of numbers and in your directive, tell the user to the proper set of numbers to use.  The script would have to break the question with OCR, understand that you wanted to use the 3rd set, or the top set or the red letters to evaluate a very simple problem like type them in reverse order.  The program could also render multiple results sets but use css to hide all but the one the user should utilize.  Trying to process 10 - 20 images of distorted numbers could send that script into a fit.

Properly designed, this directive could be very difficult for anything but a human to solve it.   

Sending the response

The same rules for current captchas apply.  Enforcing one time use, setting a time limit on the service you are protecting are good techniques.  You should also utilize css to hide multiple input fields for the answer.  The user will only see one field but the script can see multiple. If a value or the wrong value shows up in the hidden field then you know it was provided by a script.  CSS could be used to hide 20 or thirty response fields, or you could just position the decoy fields under the real input.

Taxing the captcha cracker

So as we build a captcha engine we can utilize a different directive that has to be interpreted before it can be applied against the set of data.  Now instead of just running OCR libraries against the script will have to infer the meaning of the directive against the dataset to provide the proper response.  If this is done correctly this is a much harder problem to solve than the 1st gen 'Type the characters you see"