Re: Account Lockouts

[Mark Burnett <mb () xato net>]

There has been some talk of CAPTCHA's in this thread and I wanted to comment on them further. Although CAPTCHA's are 
very effective at blocking automated abuse, in their current form they are not an effective long term strategy. The 
problem is that with our current image enhancement, OCR, and AI technology, they can be cracked with quite good 
accuracy. Their limited use and proprietary implementations still makes them useful for now but once someone releases a 
script kiddie tool to automate CAPTCHA cracking, they will become mostly ineffective. 

Furthermore, I have seen many CAPTCHA implementations that are simply flawed. For example, instructing the user to 
select one of three choices means that a script can randomly guess and still be 33% accurate. Furthermore, I have seen 
e-mail systems that come with a collection of photos for CAPTCHA use but everyone with that program has the same exact 
photos. It would be trivial to build a tool to bypass that product's CAPTCHA feature. I have also seen image 
manipulations, such as excessive use of color or adding noise, which might seem confusing to humans but are quite 
meaningless to a computer program and do little to prevent automated interpretation. 

To test out CAPTCHA images, try this in an image editing application:
1.      Convert to grayscale
2.      Apply noise removing, deinterlacing, despeckling, and other filters
3.      Increase brightness and contrast

The results are quite surprising, often producing something that an average OCR program can accurately read.

It turns out that building a secure CAPTCHA that is universally useable and stands the test of time is quite difficult. 
Image-based CAPTCHA's obviously won't work for everyone. Language-based CAPTCHA's face language barriers. There are 
also cultural, literacy, morality, education, environmental, perception, and interpretation barriers that might come 
into play.

Another issue is how you handle failed CAPTCHA input. To be most effective against an automated attack, you must be 
consistent with their use and you should use the same error message for failed username, password, or CAPTCHA response. 
This prevents a script from knowing why the login failed, but also might be more confusing for users not knowing 
exactly what they did wrong. 

Someone earlier mentioned adding a secret question to the CAPTCHA, but you must be careful with that type of 
implementation. Before you ask a secret question, you first must know who the user is. This leads to continuity 
problems and might allow for attackers to brute-force usernames, which can also be a problem. 

So while current CAPTCHA's are interesting and, for now, quite effective, you still need to keep them in perspective as 
a short-term solution that relies heavily on obscurity for their security. They are the right idea, we just haven't yet 
figured out the best implementation, or if there even is one.


Mark Burnett



--------------------------------------------------------------------
Hacking The Code: ASP.NET Web Application Security
http://www.hackingthecode.com



On Thu, 02 Dec 2004 17:49:31 -0500, Valdis.Kletnieks () vt edu wrote:
>  On Fri, 03 Dec 2004 09:38:28 +1100, Michael Silk said:
>  
> >  And you can only "beat" the captcha in this scenario by getting the password
> >  _right_. That would mean sending out a captcha image for each password
> >  you attempt.
>  
>  But remember - once you set it up, it's the same effort for one or a thousand.
>  
> >  I can't believe you think captcha add's "no" security here. It add's a
> >  great deal
> >  of complications for someone trying to annoy the site - probably far too much
> >  to bother with.
>  
>  Well.. "too much to bother with".  That's OK - *IF* your threat model consists
>  only of attacks by people who will give up if it gets difficult, and doesn't
>  include the possibility that you're being attacked by somebody who is seriously
>  determined to make life difficult for you.
>  
>  And remember - if they know enough about your system to know that such a script
>  would do *anything*, they're either (a) an (probably very disgruntled) insider
>  determined to do you harm or (b) an outsider who's *already* invested all the
>  effort in figuring out *this* much about your setup.
>  
>  Remember - we're *NOT* discussing "how to secure it against the bugtraq exploit
>  du jour".  We're specifically discussing how to secure it against somebody who
>  is *already* doing a one-off customized script to do this attack....
>  
>  If you're not assuming an infinite amount of determination (you're allowed to
>  assume finite supplies of resources and technical clue, of course) on the part
>  of such an attacker, you need to do a re-examination of your threat model...