<!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">
Dirk Balfanz wrote:<br>
<blockquote
cite="mid:60c552b80811261821k4bf3b971w6580ec1bb10226c6@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span>
wrote:<br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><br>
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.</div>
</blockquote>
<div><br>
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?<br>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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. <br>
<br>
Allen<br>
<br>
<br>
</body>
</html>