Hi Blaine, Thanks much for the comprehensive response. I do understand the motivation but beg to differ on the general ground that, as you know, a specification is a (very) long lasting beast. As someone at Sun told me, historically, once an algorithm has started to show weaknesses to one type of attack it begins to fall against other attacks sooner or later. So we really should not settle on weak security grounds right from the start.
With regard to PHP, developers have announced PHP4 was officially EOLed in July 07 (PHP5 does support SHA-2). As for the interoperability issue, I wasn't implying people must implement all signature algos but rather that at least one algorithm (or 2 if we want more flexibility) MUST be supported in all compliant implementation. Since, as you said, all libraries out there are likely to aim at implementing all of them, there should be no harm in mandating one or two. Who knows, maybe some day we'll have an OAuth certification process where minimal interoperability will be essential. Cheers, Hubert On Sun, Nov 30, 2008 at 12:24 PM, Blaine Cook <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 28, 2008 at 11:10 AM, Hubert <[EMAIL PROTECTED]> wrote: > > > > Greetings, > > > > I had some discussions with security experts inside my company (Sun) > > about > > OAuth's signature methods and a couple issues were raised. > > > > The first one was about the decision to only define SHA1 and HMAC1 > > when they've > > been reckoned as "weak" and NIST itself recommends switching to SHA2 > > digests? > > I've read the archives (not all I'll admit) and only found comments on > > the lack of > > support for SHA256 which seems unfounded at this point. > > The lack of support is (probably) a major issue, though it does > obviously become less important over time. When we started specifying > OAuth, widespread HMAC support was new. Prior to 2006, PHP developers > needed to write their own HMAC methods, which would obviously set the > barrier too high. The main goal is to build a spec that can be used > without requiring, for example, PHP 4 developers to install C > extensions. I'm not sure if SHA2/SHA256 falls into that category at > this point or not, but that would be my main concern moving forward. > > To address your first point, there are a couple of things: > > First, OAuth is only (and security experts, please correct me here if > I'm wrong!) susceptible to preimage attacks, not simple collision > attacks. Unlike collisions, which can be found in 2^69 computations > (i.e., 60 hours on a $25-36M machine in 2005), preimage attacks > against SHA1 take 2^106 computations, which (in 2005) are "purely > theoretical" according to Bruce Schneier: http://tinyurl.com/4rl78 > > The reason here is because even if you find a collision, the data (in > 2^69 computations) used to generate that hash will be meaningless to > the web service, and therefore useless to the attacker. > > Second, and more importantly, OAuth is not obscuring information; even > if you could calculate a preimage attack in, say, six months (which is > *extremely* optimistic, probably delusional) all you get to do is make > *one* extra request to a service provider impersonating the consumer. > > If it takes six months to do that, there are a number of issues that arise: > > - the timestamp might not be valid (though the attacker could choose > one in the future, they're going to have to choose far enough ahead to > guarantee that they'll be done in time, and then they'll have to wait > until that timestamp is valid) > > - the user may have generated a new token/secret pair, completely > invalidating the attack. That is to say, if you're worried about SHA1 > preimage attacks (oh my, what a big government you have!), rotate your > token/secret pairs every few days and you'll be fine. > > The bottom line here is that the security/usability tradeoff is > important. If OAuth is so hard to use or so inaccessible to regular > developers that no-one uses it, then where are we at with security? > People will use Basic Auth or pass random strings in plaintext URL > parameters for "extra security". > > While it's important to carefully consider security mechanisms and the > implications thereof, security as practiced is far more important to > me than security as theory. We did switch from MD5 to SHA1, and from > SHA1 to HMAC-SHA1 for good reasons. > > > The second issue was to not mandate at least 1 signature > > method. This could lead to bad situations like having 2 > > conforming implementations not being able to interoperate. > > In general, library authors (particularly of libraries targeted at > clients) should aim to implement all available signature methods. > Because different services have different requirements, there's little > sense in mandating that each implementation implement all of the > signature methods. I'd expect the most that would come during the IETF > process would be a "SHOULD implement" with respect to client > developers, but I definitely wouldn't support a "MUST implement", > particularly for service providers. > > I hope that helps! Obviously, these are just my opinions, and as OAuth > is a community-driven spec, others may see it differently. > > b. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
