Dirk Balfanz wrote:
On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
