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

[Breno de Medeiros]

Interesting point, and probably worth adding to a security portion of the spec.

I would say though, that is bad security hygiene to share the same
consumer key between your web and desktop apps. Since we can't vouch
for consumer keys stored in desktop apps anyway, I would volunteer
that the most sensible thing is to have empty consumer keys in that
case (and warn users that we can't vouch for the origin of the
request).

On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> Dirk Balfanz wrote:
>
> On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <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
>
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)