Ben Laurie blathering

Security Is Hard: Live With It

I’ve been meaning to summon the energy to write about OAuth WRAP. It’s hard to do, because like OpenID, OAuth WRAP is just so obviously a bad idea, it’s difficult to know where to start. So I was pleased to see that Ben Adida saved me the trouble.

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.

Exactly. The idea that security protocols should be so simple than anyone can implement them is attractive, but as we’ve seen, wrong. But does the difficulty of implementing them mean they can’t be used? Of course not – SSL is fantastically hard to implement. But it is also fantastically widely deployed. Why? Because there are several open source libraries that do everything for you. Likewise every crypto algorithm under the sun is hard to implement, but there’s no shortage of libraries for them, either.

Clearly the way forward for OAuth is not to dumb it down to the point where any moron can implement it, the way forward is to write libraries that implement a properly secure version, and have everyone use them.

If the amount of effort that has been wasted on OAuth WRAP (and OpenID) had instead been put instead into writing code for the various platforms then we would probably now have pretty much universal support for OAuth and no-one would be whining that it’s too hard to implement.

Instead, we will spend the next decade or two clearing up the mess that we seem to be intent on creating. It makes me tired.


  1. Amen.

    Comment by Paul C. Bryan — 5 Jan 2010 @ 18:44

  2. Nonsense. I’m not about to use somebody else’s untrusted code to implement authentication on my site.

    I’ve tried to implement OAuth. I failed because it’s difficult to understand exactly WTF is going on at any given point. The protocol is dense and confusing. Result: I dropped it and didn’t bother implementing it. Nor will I. Even if somebody comes out with a library to do it for me, I’m simply not going to bother.

    If I can’t understand how the protocol works, then I’m not going to use it, under any circumstances. OAuth has this fundamental problem, as does OpenID. There’s other problems with it as well, like the redirection issue, but that’s the big one. The documentation is virtually non-existent, the terminology makes no sense, and implementing it is straight-up hard.

    This is why OAuth is a failure.

    Comment by Otto — 6 Jan 2010 @ 16:34

  3. You’re absolutely right about the value of good tools as a way to drive technology adoption. However I believe “just use tls” will be hard to shake. I think there is a case for educating protocol designers (and sometimes you have to use that term very loosely) about channel bindings in the sense of RFC5056 and draft-altman-tls-channel-bindings. If commonly used tls libraries exposed cb tokens and applications developers knew how to use them (and if pigs grew wings you say…) some of the issues you and Ben Adida point out might be addressed.

    Comment by Leif Johansson — 6 Jan 2010 @ 17:09

  4. While I am not familiar with the details of OAuth, I disagree with your sentiment. SSL is one of the most document, audited and studied protocols on the planet. There are extremely mature implementations readily available.

    If you can’t leverage this in another protocol by specifying that it requires the use of properly set up SSL with mutual auth, then what is the point of SSL existing? Requiring higher level protocols to employ cryptographic mechanisms that mimic SSL seems silly. Most people will get it wrong, both from a design and implementation point of view. Its an even bigger waste of time than whining.

    Comment by drrr — 6 Jan 2010 @ 23:38

  5. I understand that they can ‘just use’ SSL instead of their own nonces, timestamps, signatures etc in OAuth WRAP. What I don’t understand is why they are pushing a new, incompatible spec at this point. What does something thats functionally equivalent but incompatible win us?

    Why don’t Facebook just use OAuth – am I missing something?

    Does keeping track of nonces and timestamps have that much more overhead than SSL?

    Would love to know the motivation behind OAuth WRAP. OAuth libraries exist today for practically every language and don’t seem that hard to me.

    Comment by Niall O'Higgins — 9 Jan 2010 @ 1:30

  6. I was unfamiliar with the reasons for your disdain for OpenID so I went back and read some of your old posts, good stuff. As for cleaning up messes, does it really take that long? I get the impression that people just create a mess, change their mind, then create another mess 😉 , over and over again. Most of these companies don’t make it and the ones that do get to enjoy the fruits of their knowledge. 🙂 Ultimately it’s about experimentation and coding up this stuff is sufficiently cheap that one can’t begrudge them trying different paths, though one can certainly despair at such obviously bad choices.

    Comment by Ajay — 11 Jan 2010 @ 14:20

  7. Ben, are you arguing that we shouldn’t rely on SSL? OAuth WRAP (and for that matter, OAuth 1.0 PLAINTEXT) rely on SSL to mitigate the attacks mentioned. Ben Adida’s argument is that SSL libraries won’t save you because people can misconfigure and misuse the libraries. But OAuth libraries will save you; apparently they can’t be misconfigured. There seems to be a small contradiction here. Especially since OAuth is much less mature than SSL.

    I am on the fence about the incompatible-spec bit. However we’re talking about a potential OAuth 2.0 here, which would have new modes not compatible with earlier clients anyway. Token renewal is a big feature that was missing from OAuth and really needs to be in there, this is a big change that will require substantial new code. No one is saying that OAuth 1.0a will stop working.

    Remember also that OAuth 1.0 signatures cover only the URL used in the HTTP request. They do nothing to protect the payload from modification. So unless you can fit everything important inside a 4K URL or are using SSL, you’re sending your data around unsigned.

    Finally, the OAuth dance is also vulnerable to MITM or DNS spoofing unless it’s initiated from an SSL connection (to obtain the token secret). So no matter what you do, if you want real security, you need to get SSL right. If you’re getting SSL right, does an additional signature actually help?

    Comment by John Panzer — 13 Jan 2010 @ 18:20

  8. […] response to my post on OAuth WRAP, John Panzer asks [A]re you arguing that we shouldn

    Pingback by Links » Is SSL Enough? — 13 Jan 2010 @ 21:16

  9. JohnP, a number of points in response to your message:

    – of course oAuth libraries can be configured wrong, but in oAuth WRAP, *one* error of omission, forgetting to check the cert, which we know is all too common, and you’re fully compromised. In oAuth CLASSIC, the equivalent damage would require you to send your secret along in the request, which is a lot less likely to happen by mistake.

    – I’m all for token renewal protocols, but that can and should be independent of how you authenticate a single request with a given active token. You can add token renewal on top of the existing oAuth protocol.

    – not quite true about oAuth 1.0 sigs covering only the URL: they cover the payload if it’s form-url-encoded, which it often is. And if you want it to cover the payload, you can use the oauth-body-hash extension. Now, should oAuth 2.0 not be broken so as to be compatible with PHP? Yes, absolutely, but again that’s orthogonal to the issue I was pointing out.

    – you make a good point about SSL in the oAuth dance. I don’t think it’s quite as bad, because the dance happens a lot more rarely than API calls, but it still is a problem. My conclusion then is to improve the dance, not to weaken the API calls.

    – to say “well, this piece needs SSL to work perfectly, so we’re safe depending on SSL everywhere working perfectly” is a poor way to design security protocols. You want defense in depth, not have your entire architecture fall apart with one failure.

    Comment by Ben Adida — 14 Jan 2010 @ 1:00

  10. Otto: OAuth, is a piece of piss. But finding a laconic solution isn’t. If you can read PHP then hit…. And if that’s gibberish to you, god save me, contact me and i’ll answer your questions.

    Comment by Drew — 9 Mar 2010 @ 18:29

  11. Second time lucky

    Comment by Drew — 9 Mar 2010 @ 18:30

  12. OAuth really isn’t that hard. It’s one of these things that, once you’ve had that light bulb moment, it all fits into place. I admit the documentation is non-existent, leaving you only with the spec, which can be a little daunting. However, the logic of it as actually pretty straight forward:

    1. You ask for a request token.
    2. You direct the user to Service Provider to allow your request token.
    3. You exchange the request token for an access token.
    4. You use the access token to allow you to do all your tasks.

    When I first saw this I thought it was a waste of time separate steps 1, 2 and 3. In fact the reasoning behind this is sound: we don’t trust anyone, not even our user. Steps 1 and 3 (which are the bits that are important to be secure) are done between your server and the service provider – without relying on the user to carry important information about the place.

    The only other complication comes from the signing of requests. Again this is easy once you’ve got it working once.

    I’m building a library at the moment called OAuthMadeEasy, which is designed to make OAuth projects a lot easier to implement. (One function handles steps 1, 2 & 3 for you, making the flow more logical for the developer. I’m also going to write some proper documentation for OAuth. I’ll keep you posted. Hopefully you’ll see that it can actually be a useful tool.

    Comment by Alexander Shepherd — 27 Aug 2010 @ 14:41

  13. […] Google’s top security experts and the OpenSSL project lead writes in his explanation why WRAP “is just so obviously a bad idea, it’s difficult to know where to start”: The idea that security protocols should be so simple than anyone can implement them is […]

    Pingback by OAuth Bearer Tokens are a Terrible Idea « hueniverse — 29 Sep 2010 @ 20:09

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress