On OAuth

This is more of a technical article, but it's pretty concise. Still, if you fear technology, you might want to stop reading, shut off your computer, seal it in cement, and drop it off in the ocean.

OAuth, to put it simply, is a protocol that securely allows users to trust a third party application with their data somewhere else, and never have to give up their password. I discovered the protocol when I was doing some Twitter stuff for work, and I'm quite impressed by it.

I'll give an example of how Starwing (a message board I frequent) might use such a service. Say I made an application that made the forum seem like an email client, namely Gmail. (Gmail organizes emails into "threads", like a message board, but that's as far as it goes without getting into extra details.) So, my client acts like a Gmail reader for Starwing, and allows you to read and, optionally, write new messages.

The obvious way to do this is for my application to request and store your Starwing username and password, then send a background request that actually uses Starwing's login form to log you in behind the scenes. A lot of applications do this, and it's not a horrible idea (especially for a plan B if OAuth went down for some reason), but obviously the passwords must be stored in plain text, that is without any encryption, so if the list was ever compromised then the attacker has the actual passwords to the service.

Another bad thing is that once our email-like application has logged in with the username and password, it can literally do anything, even change the password. Or a bug in the application might do horrendous things to the user, for example posting unwanted messages or deleting itself. And then the user has to worry about the creators of our email application going maverick and putting stuff in to steal the passwords, or if they're stored somewhere in an online database, then simply looking at them.

One way around this requires a good deal of cooperation between the service (Starwing) and our email application. That is, Starwing says it will allow our application to send the irreversible encrypted password hash instead of the plain text one which it encrypts itself to match. A problem with this is that it kills one of the advantages of not knowing what kind of hashing system a service uses, so then the attacker has brute force capabilities. And if the service is cooperating with our application, then chances are our application isn't checked for brute forcing because we'd have so many potential users logging on at the same time, and more users = more forgotten passwords and attempt after attempt. (I sometimes have to through my whole list of passwords for some site if I forget which specific one I used.)

Besides these shortcomings, the application must still store the hashed value somehow, which may be less secure than the service's storage system, and if the attacker has the hash AND the algorithm, it's theoretically over for the user if he has enough computing power to brute force it. An 8 character password has 722,204,136,308,736 possible arrangements, given it uses only characters with a-z, 0-9, and !-). While this would take a very long time for a single computer to go through, a multi-computer botnet could rip through it. If you had a (relatively) small botnet of a million computers, and only had each one try a billion combinations (a matter of seconds), then you're already on the right order of magnitude for the amount of things to crack. (i.e. 100,000,000,000,000.) Decrease the botnet size, increase the amount to test. It doesn't get theoretically impossible for a while, at least with just 8 char passwords. (My 34 character one is essentially resistant to these attacks for its length alone.)

Enter OAuth. Now let's describe what happens when the user wants to authorize our email system access to their account. We set up an account with Starwing to label our application as a third party. We get back two encrypted values called our key and secret that our application uses to verify that we're really us. So now, a user clicks a link in our application, which takes them to Starwing itself. There, they enter their username and password if they're not logged in, and now they're authenticated only on Starwing. They're greeted with an option saying that our application wants to have read and possibly write access to their account. How much our application can read and how much it can write is determined by Starwing itself, though it could also probably be determined by users in some situations. This means that our application could never change things such as a password, or Starwing can have message limits to prevent flooding.

So now what happens when the user clicks their agreement? They're redirected back to some link on our application, along with a few signed hashes that our application then sends back to Starwing, and Starwing then sends us two hashed user tokens, a key and a secret. We store these, and we use them to authenticate to Starwing through OAuth, without ever having access to the user's password.

Now, if anyone has seen the tech news recently, an OAuth vulnerability was discovered. But really it's not much to worry about; it's basically the fact that our application has no automated way of knowing whether the user who clicked our button to start the process is the same who has been redirected by the server. At work we solved this without thinking about it by requiring the user to be logged in to our application before it would accept any OAuth thing. Others though don't use that, and now they're figuring out various ways of guaranteeing that it's the same person. I'm not going to pretend to understand all the cryptology involved.

So, that's OAuth. I think it's pretty sweet, and that every third party application that connects to another third party application should use it. This lets the user be at ease when they give access to their account, since their password is never stored in plain sight.

---

Posted on 2009-06-12 by Jach

Tags: programming

Permalink: https://www.thejach.com/view/id/2

Trackback URL: https://www.thejach.com/view/2009/6/on_oauth

Back to the top