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. |

| 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...
pgpvLpn8gHF8o.pgp
Description: PGP signature
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Account Lockouts, David Robert |
|---|---|
| Next by Date: | RE: Account Lockouts, Alexander Klimov |
| Previous by Thread: | RE: Account Lockouts, David Robert |
| Next by Thread: | RE: Account Lockouts, Alexander Klimov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |