Should API Secrets used for simple authentication be hashed in the database?

Question

There was a similar question which I found which was asked the better half of a decade ago "Is it okay for API secret to be stored in plain text or decrypt-able?", but the majority of answers seem to revolve around API security schemes where the secret is used as a key, for example, to produce a hash, in which case the answer is of course that you need to have a full copy of it available.

However, there are other API schemes, if we take a look at Stripe, for example, you can see that essentially the secret is used as a password in a request header:

https://stripe.com/docs/api/authentication?lang=curl#authentication

I have no particular insight into how Strip operates, but there is of course some level of a performance hit if you allow there to be multiple active API keys assuming you use any reasonable hashing scheme.

Now I can think of a way of avoiding this (such as including in the key some sort of identifier which can be used to pull back the specific hashed version), but that doesn't seem to have been done here.

So, is there some reason why you would not need to hash this data? It seems like it is just as important as any password, with perhaps the exception to the fact you know it's not being reused on other websites.

Answer 1

I work for Nike as a penetration tester/adversarial simulation specialist, and we typically will mark API keys that are stored in plain-text as a high/critical vulnerability. Understandably, API keys will have to be stored somewhere in order to be used. Most often we will recommend the following to our stakeholders:

Use strong symmetric encryption to encrypt the key before storing on device. Use obfuscation to make the discovery of the decryption key for the API key more difficult. Limit the functionality and privileges of the API to only do what it needs to do (principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege)

These two things when implemented correctly will deter most attackers from getting your keys. But if you do have to store the keys on device for some reason, just know that it is possible for a dedicated attacker to get those keys if they try hard enough.

Lastly, you may consider using something like AWS secrets manager, because it sounds great. Amazon's secrets API must be secure! Wrong, you're still left with the original problem of having to secure an API key. But now the API key you have to secure is an API master key that will give an attacker access to all your API keys for all your AWS apps. By using secrets manager, you effectively increase the scope that a breach of your API key encryption would have (good for attacker, bad for devs). We see this a lot and always recommend against it.

Finally I'll point you to another Stack Exchange question: Do I need to hash or encrypt API keys before storing them in a database?

I hope these considerations answer any questions you had.