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?


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.

  • Do you backup your database? What happens if someone gets ahold of a portion of the backup?
    – jjanes
    Sep 18, 2014 at 15:12
  • The backups will all be encrypted.
    – lzam
    Sep 18, 2014 at 15:13
  • I think your terminology is confusing folks. I think (correct me if I'm wrong) that what you refer to as an API "password" is more commonly known as an API key Sep 18, 2014 at 16:11
  • @ChrisMurray Close, Often "API Keys" refer to identifiers, which may (or may not) also be used for authentication. This is not the case in our situation. We have seperate identifiers and "authentication" factors for API consumers.
    – lzam
    Sep 18, 2014 at 16:17

2 Answers 2


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.

  • We are not going to be transmitting any API passwords in the clear. Also if we are breached I don't think the API credentials are what's going to be on anyone's mind. Regular user passwords (which people will care about) are salted and hashed.
    – lzam
    Sep 18, 2014 at 15:33
  • 3
    People care about any password @Izam. The press don't know the difference between a user password and an API password, and neither do the majority of people. They see passwords unsecured and that's it.
    – GdD
    Sep 18, 2014 at 15:36
  • You didn't answer the part of the question about salting. In this case, where passwords are long and unique, salting doesn't provide much value, yes? Oct 24, 2021 at 5:26

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .