OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
>
> On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <atom at yahoo-inc.com 
> <mailto:atom at yahoo-inc.com>> wrote:
>
>
>     In Section 10, and perhaps also in Section 12, the spec should
>     mention that because the hybrid protocol does not have a request
>     token secret, and because the user is never required to manually
>     type in the request token (unlike in OAuth), the hybrid Request
>     Token probably should be longer and harder to guess than the
>     standard OAuth Request Token. At least for our implementation, I'm
>     thinking that the hybrid RT == OAuth's RT+RTSecret.
>
>
> But you need to have the consumer secret to exchange it, no? What if 
> it were just a incrementing integer? What would the attack be?
Yes, the attacker would still need the Consumer Secret, however in 
vanilla OAuth, the attacker would need the Consumer Key, Consumer 
Secret, Request Token, and Request Token Secret. Because there's one 
less secret, the Access Token could be more vulnerable to hijacking from 
brute force attacks where RTs are just randomly scanned.

In our case, Yahoo issues relatively short Request Tokens from a limited 
character set to make them easy to type. We compensate for the short RTs 
by pairing them with long RTSecrets. If we were to implement the hybrid 
protocol, our hybrid RTs would be much longer than the regular OAuth RTs.

We also believe that developers may inadvertently leak their Consumer 
Secrets. We're seeing lots of questions from developers who are trying 
to use OAuth from within Javascript and Flash, which implies that 
they're going to be leaking the secret to the browser. Developers may 
also reuse their website's Consumer Key into a downloadable client 
application.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20081202/72c4bb7a/attachment-0002.htm>