<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.
<br>
<br>
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.<br>
<br>
Allen<br>
<br>
Breno de Medeiros wrote:
<blockquote
cite="mid:29fb00360812021643h3d105667g98794de261add223@mail.gmail.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:atom@yahoo-inc.com"><atom@yahoo-inc.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dirk Balfanz wrote:
On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <a class="moz-txt-link-rfc2396E" href="mailto:atom@yahoo-inc.com"><atom@yahoo-inc.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>