captcha challenge

[Marius Scurtescu]

The Username and Password profile defines two 400 responses, a
verification URL and a captcha challenge.

The verification URL response is pretty straightforward, but not sure
how the captcha challenge should be interpreted and dealt with.

wrap_captcha_url is defined as the URL to a captcha puzzle and the
client must present this puzzle to the user and ask for a solution.
Based on the available information it seems that the client should be
able to render an HTML page.

If the client can render HTML, then maybe the verification URL is good
enough and there is no need for the captcha challenge as well. The
only difference would be how the solution is captured.

If the spec wants to accommodate clients that cannot render HTML, then
maybe it should be specified that wrap_captcha_url points to an image,
or that the authorization server defines the content type.

Marius

[Dick Hardt]

The wrap_captcha_url points to an image of the puzzle. Thanks for pointing out that this needs to be clarified.

-- Dick

> --
> You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
> To post to this group, send email to oauth-...@googlegroups.com.
> To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
>

[Alan Karp]

Should the protocol use recaptchas instead, or is that included already?

--------------
Alan Karp

[Dick Hardt]

I think that would be an implementation detail.

[Allen Tom]

Hi Marius -

Not sure if you got a response about the 400 response for the
username/password profile.

The wrap_captcha_url is supposed to be the URL to an image - not to an HTML
page. The username/passsword profile is intended for clients that either
don't have or don't want to use a browser - so we wanted define a mechanism
for rich clients to support the entire flow without requiring a browser. For
implementation purposes, it would probably make sense for the Client to know
the dimensions of the image, as well as the string length of the solution.

The wrap_captcha_url was modeled after Google's Client Login
"CaptchaRequired" response:

http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

Yahoo has a virtually identical interface for our private auth APIs. (We do
not have any public documentation on this interface, so I can't link to it)

Yahoo's auth interface also has the equivalent of verification URL, where
the user is informed to Login to Yahoo using a web browser. This interface
is a lot more widely used than the CAPTCHA URL. I think it makes sense to
have both interfaces.

Hope that helps
Allen

[Marius Scurtescu]

Hi Allen,

Yes, Dick clarified that it is supposed to be the URL of an image, and
he actually made that explicit in the last version of the spec.

I still think this is problematic in practice, as you mention, you
don't know the size of the image and of the solution. Also, for
accessibility reasons most captcha implementations allow you to either
generate another image and/or switch to an audio one, and for this you
need full HTML.

Thanks,
Marius

[Allen Tom]

Hi Marius -

One of the main disadvantages to the Verification URL is that the user's
account could be in this special "lockout" state because an attacker is
actively trying to crack their account. Even if the user were to manually
visit the Verification URL in their browser, the account could be be placed
back into the locked state before the client is able to retry.

This specific case could be addressed by requiring CAPTCHA to verify the
user's password.

At least in Yahoo's case as an SP, we can support both the Verification URL
and CAPTCHA interfaces, and we'd be OK with only having Verification URL.
However, it seems that the intent of the username/password profile is to
support rich clients without requiring any browser support, so the intent of
the captcha interface was to enable a full end-to-end solution for these
clients.

Allen

[Marius Scurtescu]

On Thu, Jan 21, 2010 at 3:04 PM, Allen Tom <at...@yahoo-inc.com> wrote:
> Hi Marius -
>

> One of the main disadvantages to the Verification URL is that the user's
> account could be in this special "lockout" state because an attacker is
> actively trying to crack their account. Even if the user were to manually
> visit the Verification URL in their browser, the account could be be placed
> back into the locked state before the client is able to retry.
>
> This specific case could be addressed by requiring CAPTCHA to verify the
> user's password.

In WRAP's case, the CAPTCHA challenge will follow the username/password
entry, and as far as I can tell it is not meant to be shown at the same time and
not with every username/password entry. Considering that, the two error
responses seem to me just as (un)effective at preventing lockouts.

> At least in Yahoo's case as an SP, we can support both the Verification URL
> and CAPTCHA interfaces, and we'd be OK with only having Verification URL.
> However, it seems that the intent of the username/password profile is to
> support rich clients without requiring any browser support, so the intent of
> the captcha interface was to enable a full end-to-end solution for these
> clients.

Yes, I can see that use case. I was just wondering if the current spec
is detailed
enough to be of help.

Marius