4

I'm developing an API and used a recommended implementation of OAuth2 protocol: PHP OAuth2 Server.

This library stores client ID and client secret as plain text in a database table.

Note that I mean the API clients' credential, not users' credentials.

I'm concerned about the case of an attacker gains access to the database, he will be able to use obtained data at will, unlike hashed+salted stored passwords that take a long time to be made useful.

This is really a security risk? How could security be improved, beside firewall and user permissions?

PS: Checked this question but my application run on *nix servers

1 Answers1

3

I wouldn't consider this a major security issue as the values are limited to only your system's access to the third party sites. It is less desirable, but the values can be easily invalidated without any bleeding in to other systems that access the same services. It certainly doesn't hurt, and is even wise, to encrypt it, but you would have to encrypt it with a value found on the server anyway, so it only adds a mild amount of difficulty in gaining access to the keys. You can't hash them like you would a password since they are just a token value that has no relation to any user input you ever see.

Depending on your use case, you could use the user's password for your system to encrypt the values (if you aren't using oAuth for your system's authentication), and you could only grab and hold the tokens while the user is logged in (if using oAuth for authentication), but that limits things like your ability to do any interactions while the user is offline, which may not be a viable constraint in your system.

Use of those keys should be restricted to your applications access to the third party systems and may well be limited to just your server's access to those systems as well, depending on how things are setup.

They are of pretty low value to an attacker. It is a good idea to take what measures you can to protect them, but I wouldn't classify them as nearly as sensitive as a password (which is highly likely to be used elsewhere and gives direct access to the account).

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110