On Tue, Dec 2, 2008 at 4:58 PM, Allen Tom <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > Dirk Balfanz wrote: > > On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[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 > > > > > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
