Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: Account Lockouts

Subject: Re: Account Lockouts
Date: Thu, 09 Dec 2004 11:06:52 -0500
On Thu, 09 Dec 2004 01:26:31 EST, David Robert said:

3) map out the parameter space so that humans have an easy time and OCR
programs don't.  This would be a bit of work but I expect the parameter
space to be contiguous.  I'm not sure this would be possible otherwise.

Satisfying the "humans" and "OCR" requirements at the same time is a lot harder
than it looks.

(OK.. Maybe it's just the fact it's a dreary morning out there, and I'm
fighting off a rather nasty cold, and my eyesight isn't all that hot on a GOOD
day.  But right now I'm having *enough* trouble reading a nice ISO9241 font -
if I hit a captcha distorted enough to stop an OCR program, things would come
to a screeching halt.  That's just me, today - but good user interface design
requires that you realize that users *DO* have days like that....)

5) to generate a CAPTCHA, just generate a random series of alphanumeric
characters, create an image from them, and apply a random transformation.

As somebody else already noted, you don't even need good OCR - they managed to
apply a mostly-brute-force attack that did fairly well.  Remember, you can't
apply *TOO* big a distortion, because otherwise you have problems with users
not being able to distinguish 'c' and 'o', and so on.  Knowing that, and the
legal charset, it's not a hard problem at all (remember that the biggest problem
in doing "true" OCR is the possibility that the program has to deal with input
that includes doodles, wrinkles in the paper, coffee stains, and the like - none
of which is an issue with trying to decode a captcha).

I agree this is not perfect.  There is a chance that the CAPTCHA will be too
hard to read. But that can be tuned to minimize this to an acceptable level.

OK.. are you advocating inflicting the tuning process on your end users, or do
you have a human-factors test lab in place?  Note that this *is* an important
question - if you release the product with the level mis-tuned, you have some
*real* problems.  If it's "too easy", an OCR program can beat you and you're
providing false security, but if it's "too hard", you've just prevented
legitimate users from getting at the resource.  And keep in mind that "users"
often mean "fickle customers" who might go to the competition if you piss them
off too much...

Attachment: pgpvLpn8gHF8o.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>