Subject: [OAUTH-WG] Username and Password flow: no captcha?

From: Andrew Arnott <[email-masked]>
Date: Mon, 7 Jun 2010 08:40:42 -0700

In WRAP, there was a CAPTCHA in this profile, but I don't see it in the
latest OAuth 2.0 draft.  Since I've already implemented the CAPTCHA stuff
from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or
rip it out now if OAuth 2.0 decided it wasn't necessary.

Does anyone from the WG have something they can say on the subject?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: Luke Shepard <[email-masked]>
Date: Mon, 7 Jun 2010 11:30:08 -0700

The username/password flow is designed to work in a situation where there is no web browser available. At least at Facebook, none of our clients implement captcha - it doesn't really make sense in many contexts.

A provider is still welcome to offer a non-standard captcha support but it shouldn't be part of the core spec.

On Jun 7, 2010, at 8:40 AM, Andrew Arnott [email-masked]<mailto:[email-masked]> wrote:

In WRAP, there was a CAPTCHA in this profile, but I don't see it in the latest OAuth 2.0 draft.  Since I've already implemented the CAPTCHA stuff from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or rip it out now if OAuth 2.0 decided it wasn't necessary.

Does anyone from the WG have something they can say on the subject?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

<ATT00001..txt>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 7 Jun 2010 11:40:20 -0700

Background: The username / password flow can be used to brute force attack a system to find valid credentials. A captcha is presented to slow the attack down -- similar to what happens when you log in with an invalid password on a webpage.

The captcha would be displayed by the app for the user to enter in if the AS thinks it is getting attacked from that IP or whatever. The captcha does not require a web browser -- it actually does make sense for most of the Facebook clients. 

The captcha was dropped because there were a number of aspects that had not been standardized, so it was decided to drop it from the core.

On 2010-06-07, at 11:30 AM, Luke Shepard wrote:

> On Jun 7, 2010, at 8:40 AM, Andrew Arnott [email-masked] wrote:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 7 Jun 2010 16:24:02 -0400

What if the username/password (or PIN) was used to release a secret (located in an OTP dongle) or to exercise a secret key (symmetric or asymmetric) located in a smartcard or TPM chip?

Reading Section 3.8, it seems it covers these cases already (or am I reading the wrong section). In Figure 6, the "Client" would be the code contained in the auth-device (or the code that invokes the underlying auth-device).

Section 3.7 on device flows does not look as if it was written with these portable auth-devices in mind.

/thomas/

__________________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Monday, June 07, 2010 2:40 PM
To: Luke Shepard
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Username and Password flow: no captcha?

<ATT00001..txt>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Mon, 7 Jun 2010 18:21:27 -0700

On 2010-06-07, at 1:24 PM, Thomas Hardjono wrote:

> Reading Section 3.8, it seems it covers these cases already (or am I reading the wrong section). In Figure 6, the “Client” would be the code contained in the auth-device (or the code that invokes the underlying auth-device).
>  

Correct, it was not.