I am dealing with a system (in development) that uses randomly generated (not user provided), unique, strings to authenticate services that will consuming an API. Right now, these strings are stored in the database in plain text.
I would like to understand if there is a strong reason to re-engineer this system, so that these strings are salted and hashed.
My understanding of the reasons for storing passwords only as salted hashed is as follows:
- An attacker may gain access to your database.
- At this point you don't have much left to loose, the attacker can already access your customer's data, and do pretty much whatever he wants. User passwords are a moot point. HOWEVER...
- Your users may be using the same password for other things. If you don't salt and hash properly, the attacker can use the stolen credentials to gain control of other resources, that have nothing to do with your system (besides sharing the same users, with bad password habits).
In other words, the point of salting and hashing passwords is to protect users from the consequences of password reuse. In my case, however, password reuse should not be a factor.
Is there still a strong reason to modify the system to salt and hash these "passwords" as well?
At least some of these API keys are going to end up embedded into widely distributed applications anyway. The API key alone will not be enough to access all sensitive information. A regular username and password will also be required in most cases. Certain API users with special privileges will be restricted by IP address.