Re: reCAPTCHA: AOL's CAPTCHA

Hey,

On Wed, 18 Jul 2007, Gez Lemon wrote:

> On 18/07/07, Ben Maurer <bmaurer@andrew.cmu.edu> wrote:
>> Once a user solves a specific CAPTCHA, they can not be allowed to use the
>> CAPTCHA again. Otherwise you could amplify a human based attack by
>> re-using human solutions. It's not that the code can't be done, however
>> getting the security aspect of it right is a bit harder.
>
> The usability aspects make it worth the extra work to getting the
> security aspect right, in my opinion. At the moment, AOL do re-present
> the same CAPTCHA, so if they're not safe-guarding against this right
> now, it's something they will need to address.

Ok, so that's pretty obviously a bad idea. Either they got the security 
stuff right (and they should just not show the CAPTCHA the second time) or 
they didn't (and need to fix their code).

>> Also -- it's a lot easier to just validate in JS on the client side. Then
>> on the server side you only need to validate for non-js clients (and to
>> protect against evil users). In this case, having the "hide the CAPTCHA"
>> functionality would be unnecessary.
>
> That would depend on how the errors are reported to the user.
> Client-side validation could also be used to verify the CAPTCHA with
> Ajax, and removed if it is okay.

Brings up more security issues. Let's say you have a callback via ajax 
(captcha token, user's answer) -> (boolean). Then when you submit the 
form, you pass the token & answer back to the server for the final 
validation. This approach can give the user two attempts at a single 
CAPTCHA (eg, an attacker could pass the best two guesses from OCR).

In general, code that does things like allows CAPTCHA solutions to be 
reused in some cases or that allows two attempts to be made at a CAPTCHA 
are *really* easy to get wrong. They make the code hard to audit for 
security.

-b

Received on Wednesday, 18 July 2007 20:42:14 UTC