Is there a strong reason to salt and hash passwords when password reuse is not an issue?

Question

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:

1. An attacker may gain access to your database.
2. 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...
3. 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?

Edit:

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.

Answer 1

It's a fair question there are considerations you may not have thought of:

• There are ways attackers can get access to parts of your database without accessing all of it, so your point 2 isn't quite correct. Coding errors can leak data, as can sql vulnerabilities. An attacker could get a dump of your passwords and nothing else
• If you aren't storing your passcodes hashed then you probably are transmitting them in the clear in which case they could be sniffed if you are not correctly using SSL. Hashing these would provide defense in depth against attacks against transmission
• Hashing stored passwords shows due diligence and a commitment to security. If you got breached and it became known that you weren't hashing your passwords it would look bad, even if your reasoning was sound. If you were audited it would look bad as well

My advice would be to hash your passwords, it's easy enough to do and the benefit is there.

Answer 2

I've actually pondered this exact issue before. If your API key is basically only used for insertion, the real issue is the key leaking and bad data getting into a user's account. It sounds like you have adequate security controls for what is truly important: user access to data. I don't see any need to hash these necessarily. Ideally any authentication credentials even write only and no read) should be hashed, but since the system is already built, I understand that it can take a big effort to change. I would just ensure users are aware they need to keep their API keys a secret and not share them.