Securly Storing OpenID identifiers and OAuth token

问题:

I am creating a web app that will use OpenID logins and OAuth tokens with Youtube. I am currently storing the OpenID identity and OAuth token/token secret in plain text in the database.

Is it inappropriate to store these values as plain text? I could use a one-way encryption for the OpenID identifier but I don't know if that is necessary. For the OAuth tokens, I would need to use a two-way encryption as my app relies on getting the session token for some uses.

Is it necessary to encrypt the OpenID identity? Could someone use it to gain access to a user's account?

回答1:

First, there is a registered application that has consumer_key and consumer_secret.

When users authenticate and "allow" your registered application, you get back: an access_token that is considered the user's "password" and would allow JUST YOUR application to act on the user's behalf.

So, getting just the user's access_token from your database won't help much if they don't also have the consumer_key and consumer_secret for complete access.

The service provider compares all 4 parameters on request. It would be smart to encrypt these 4 parameters before storage and decrypt them before response.

This is just when you need to update or make changes to the user's resource owner on behalf of a user. To keep a user logged-in on your site, use sessions.

回答2:

The OAuth Token and Secret should both obviously be kept safe in your database, but you can't store them using 1 way encryption the same way you would for a password. The reason being is that you need the token and secret to be able to sign the request.

This would also be the case if you are running an OAuth server, you still need the original token/secret to verify the request.

If you want to you could still encrypt them using a 2 way encryption algorithm such as AES to offer security in case your database or database backups get compromised.

回答3:

There's two schools of thought here.

The first argument is that: you should treat OAuth tokens like passwords. If anyone were to access your database, obtain all the OpenID/OAuth pairs and run an man-in-the-middle attack, they could impersonate any user on your site.

The second argument is this: by the time someone has access to your database and sufficient access to your network to run an man-in-the-middle attack, you're hosed anyway.

I'd personally err on the side of caution and just encrypt them; it's a standard practice for passwords, so you might as well give yourself just that little extra peace of mind.

Meanwhile, Google has this advice:

"Tokens should be treated as securely as any other sensitive information stored on the server."

source: http://code.google.com/apis/accounts/docs/OAuth.html

And some random guy on the web has specific implementation advice:

• If they’re on a regular disk file, protect them using filesystem permissions, make sure that they’re encrypted, and hide the password well
• 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.

http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/

回答4:

OpenID URL shouldn't be encrypted because this is your "open id" literally, everyone should know the value. Besides, the URL needs to be an index in the database and it's always problematic to encrypt the index in the database.

OAuth token/secret should be secret and encryption may improve security if you have to store the token long term. In our OAuth consumer application, token/secret is only stored in session for a short while and we choose not to encrypt them. I think that's secure enough. If someone can peek into our session storage, they probably have our encryption key also.

回答5:

Yes, these should be symmetrically encrypted (say, AES-256 in CBC mode) at rest in a database. A simple way to encrypt these tokens is using SecureDB's Encryption as a Service RESTful APIs.

Disclosure: I work at SecureDB.