It’s a WRAP

I’m just finding out about oAuth WRAP, a new, simplified version of oAuth which some are calling the “valet key” approach to web data sharing: don’t give your Facebook password to a random web app, instead use oAuth to mint them a valet key that lets the app access only some specific portions of your Facebook profile. I like and use oAuth, so I was a little bit confused as to what WRAP brings to the table. I read up a bit:

The main difference between OAuth and OAuth WRAP is that WRAP does not have elaborate token exchanges or signature schemes. Instead, all server-to-server WRAP calls happen via SSL. The “access token,” which grants your client the ability to make API calls on a user’s behalf, is protected by SSL rather than by a shared secret and signature scheme.

If I understand correctly, the experience is the same for the user, the connectivity requirements between the data host and the third-party consumer remain the same, but now we’ve gotten rid of those pesky signatures and instead we’re sending tokens in an HTTP header a bit like a password.

So, like a password, it can be replayed. And intercepted via Man-In-The-Middle. Oy.

But wait, you say, don’t worry, the token is sent over SSL, so it’s all good.

Right. What’s going to happen when someone “forgets to turn on SSL”, which is all too common when security is abstracted out “somewhere down in the stack.” Or when we stop dealing with those pesky certificate errors and just choose not to validate the cert, which will leave the protocol wide open to network attackers who can now literally play man-in-the-middle just by spoofing DNS on a wifi network, capturing the token, and replaying it to access all sorts of additional resources, effectively stealing the user’s credentials.

This might actually be worse than passwords, because at least you can work to educate users about SSL (and after their Facebook account gets hacked, they might actually care), but it’s very hard for users to gauge whether web applications are doing the right thing with respect to SSL certs when the SSL calls are all made by the backend which has trouble surfacing certificate errors.

I understand. Security is hard. Getting those timestamps and nonces right, making sure you’ve got the right HMAC algorithm… it’s non-trivial, and it slows down development. But those things are there for a reason. The timestamp and nonce prevent replay attacks. The signature prevents repurposing the request for something else entirely. That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling.

I see reasons to simplify oAuth. Maybe rethink the combination of consumer and access secrets, which is a bit messy. Maybe rethink the token renewal process and make it part of the core. But removing signatures? I think this is asking for long-term trouble in exchange for a modest amount of short-term simplicity.