Secretly Keeping OpenIDs and OAuth Tokens

Question

I am creating a web application that will use OpenIDs and OAuth tokens from Youtube. I am currently saving the OpenID and OAuth token / token token as plain text in the database.

Is it wrong to store these values ​​in plain text? I could use one-way encryption for the OpenID, but I do not know if this is necessary. For OAuth tokens, I will need to use two-way encryption, as my application relies on getting a session token for some uses.

Do I need to encrypt OpenID? Can someone use it to access a user account?

Answer 1

Firstly, there is a registered application with consumer_key and consumer_secret .

When users authenticate and "allow" your registered application, you return: a access_token , which is considered the user "password" and will allow JUST YOUR application to act on behalf of the user.

Thus, getting just the access_token user from your database will not help if they also don't have consumer_key and consumer_secret for full access.

The service provider compares all 4 parameters on request. It would be wise to encrypt these 4 parameters before storing and decrypt them before answering.

This is easy when you need to update or make changes to the owner of a user’s resource on behalf of the user. To have a user log in to your site, use sessions.

Answer 2

OAuth Token and Secret should be safe in your database, but you cannot store them using one-way encryption, just like for a password. The reason is because you need a token and secret to sign the request.

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

If you want you to still be able to encrypt them using an encryption algorithm with two methods, such as AES, to ensure security in the event of a database or database backup failure.

Answer 3

There are two schools of thought.

The first argument is that you should handle OAuth tokens, such as passwords. If someone needs to access your database, get all OpenID / OAuth pairs and launch a man in the middle attack, they can represent 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 launch a man in the middle attack, you will still be closed.

I personally erred on the side of caution and simply encrypted them; this is standard practice for passwords, so you could also give yourself just a little slight peace of mind.

Meanwhile, Google has this tip:

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

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

And some random guy on the Internet has special implementation advice:

• If theyre in a regular disk file, protect them using the permissions file system, make sure theyre encrypted and hide the password well
• If theyre in the database, encrypt the fields, save the key and provide access to the database. *
• If theyre in LDAP, do the same.

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

Answer 4

The OpenID URL should not be encrypted, because this is your "open identifier" literally, everyone should know the meaning. In addition, the URL must be an index in the database and it is always problematic to encrypt the index in the database.

The OAuth token / secret must be kept secret, and encryption can improve security if you need to keep the token for a long time. In our OAuth consumer application, the token / secret is stored in the session for a short time, and we prefer not to encrypt them. I think it is safe enough. If someone can peer into our session memory, they probably have our encryption key.

Answer 5

Yes, they must be symmetrically encrypted (say, AES-256 in CBC mode) alone in the database. An easy way to encrypt these tokens uses SecureDB Encryption as a RESTful API.

Disclosure: I work for SecureDB.