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

[Breno de Medeiros]

On Tue, Dec 2, 2008 at 4:58 PM, Allen Tom <atom at yahoo-inc.com> wrote:
> It's definitely bad hygiene for developers to leak their secrets to the
> browser, or to reuse their website's CK for a downloadable client
> application, and we're doing all that we can to encourage good hygiene.
>
> For the time being, we prefer to require CKs for client applications (even
> if they can't be verified) mostly to make it easy for us to pull the plug on
> specific applications if they are discovered to be severely buggy or
> dangerous. We'd also like to require pre-registration of CKs so that we know
> who to contact about a particular app if we have any questions.

Sounds reasonable.

>
> Allen
>
> Breno de Medeiros wrote:
>
> 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)