December 2008

Recently, I spent quite some time working with 2 esteemed colleagues, Susan Landau and Robin Wilton, on a paper we submitted at Financial Cryptography and Data Security 2009. The paper’s title is Achieving Privacy in a Federated Identity Management System and I’m happy to report we have been accepted (Yay!).

One of the concept we develop in this paper is one I call Privacy in depth, where, in a parallel to security in depth, privacy must no longer be handled within the realm of a single site (where the data resides). Instead, privacy must be dealt with from a global perspective. This means both in time (when is data released? for how long? how many times has it been used?) and space (who uses it? and for what purpose?).

I really like this term since I think it accurately describes an evolution that will have to happen before we lose total confidence in the web’s ability to preserve what’s left of our privacy. I’ll post the paper whenever (if) possible.


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.