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 -~----------~----~----~----~------~----~------~--~---
