As promised in my previous post, here’s an update on ongoing discussions around OAuth’s signature mechanisms. Basically, the main response (thanks Blaine!) I got (here) revolves around a main argument: it’s all about the security/usability tradeoff. In other words, since the weaknesses found in SHA-1 (esp. collision ones) seems hardly exploitable and support for, say, the SHA-2 family of hash functions,  is not wide spread, it is preferable to stick to SHA-1. To be fair, it is true that chances of breakage today are slim; the addition of a timestamp makes OAuth fairly robust.

However, I disagree with the approach. SHA-1’s weaknesses are quickly increasing and it can only get easier and easier to break (just look at the evolution here). Showing weaknesses to collision will lead to weaknesses to other attacks. For this very reason, and because a standard (and its implementations or deployments) will last years, one must aim at the best security standard available at the time of specification. Also, as mentioned before, SHA-2 is really getting wide adoption these days.

The other sticking point IMO is interoperability. I still think that we should not rely on good-willing from  the implementors (no matter how great they are) to guaranty interoperability. In all the standard efforts I’ve been involved with, ensuring implementations have a minimal set to interoperate with is a MUST. I think OAuth should strive for this too and thus mandate support for one or more signature algorithm.

I’m convinced the IETF process will help addressing these concerns. In the meantime let’s keep the discussion going.