A lot has been happening with OAuth recently. Not all of it has been good — a security hole was discovered in the protocol which exposes it to a potential “social engineering” attack. Right now would not be the best time to deploy a new API that uses OAuth — in fact, my colleague Gregory Haardt is also advising a little caution.
However, the OAuth community is working on a revision to the spec that will address the issue and it will not be long before there is a new protocol version which elminates this particular hole.
I wanted to bring up a related issue, which anyone implementing OAuth should keep in mind. Namely, how do you securely manage all those keys?
For example, let’s look at how companies manage traditional username / password authentication:
Anyone following good security practices does not just have a big database on the back end with a list of unencrypted passwords. Instead, a hash of the password is stored, preferably using a salt. As a result, someone who can read the password file can very easily verify that they have the right password, but they cannot figure out what the password is if they do not already know without doing a lot of work.
It is still critically important to protect access to these encrypted passwords, of course. Otherwise, an attacker can mount a dictionary attack to try and crack them. However, even if someone gains access to your entire database of encrypted passwords, they can still only easily gain access to lousy passwords. At least users who choose secure passwords are relatively safe.
(It is also critically important to protect access to the cleartext password, but at least this mechanism doesn’t require that it be stored in a database for all to see.)
As networking and middleware people, we spend a lot of time thinking about the security of our network protocols, and especially ensuring that someone eavesdropping on a network cannot grab our passwords and other sensitive data as they fly by. This aspect of security is important, or else the Internet never would have succeeded.
But how many times have we heard of a security breach caused by a stolen laptop, or purloined backup tapes, or an administrator who decided to trade his or her privileged access for a few quick bucks? It seems to me that we hear about those kinds of attacks a lot more often than we hear about someone who stole passwords from the wireless network at Starbucks. I would argue that protecting so-called “data at rest” is just as important, or maybe even more important, as protecting the data flying around your laptop.
Now, back to OAuth. Each “user” in OAuth holds something called an “access token,” which is like a username, and a “token secret,” which is like a password. When a request is sent over the network containing an OAuth authentication token, a bunch of data in the token is encrypted using the token secret, but the secret itself is never sent over the network. That way, regardless of whether SSL is in use, there is no way to gain access to the token secret by sniffing the network.
However, on the server side, in order to validate the OAuth token, the server must make the same calculation that the client made when it encrypted the data to put in the token. That means that both the client side and the server side in OAuth must be able to read the unencrypted token secret from some sort of database. Without it, OAuth doesn’t work. There’s no set of standard ways for storing those keys like there are for passwords, so presumably different implementations are storing them in different ways.
As a result, any client and any server that uses OAuth has to take extra-special care with all those token secrets. Otherwise, anyone who gets access to the database of tokens and secrets used by the back end servers immediately has access to all the OAuth-enabled accounts.
I am not suggesting a change to the OAuth protocol here — it solves an important problem (and more on that later).
However, I am suggesting that anyone who implements either the “service provider” or “consumer” side of OAuth take very special care of those tokens!
For instance:
- If they’re on a regular disk file, protect them using filesystem permissions, make sure that they’re encrypted, and hide the password well (because it’s not like you’re going to have an administrator type it in whenever you reboot, right?)
- If they’re in a database, encrypt the fields, store the key well, and protect access to the database itself carefully.
- If they’re in LDAP, do the same.
Come to think of it, perhaps the world needs a standard LDAP schema for storing OAuth secrets in a secure way. Anyone care to make a proposal?
