Should API Secrets Be Hashed?

Question

It might sound like a silly question, because passwords of course need to be hashed and never store the original.

However, for API secrets, generally I see them displayed in the clear when signing up for them.

For example, if I go to the google api console and look at my credentials page, I can view my client secret, same for twitter.

Surely api keys are just as sensitive as passwords?

Is it just because from the provider side, you can be confident that a sufficiently strong password is being generated? If that's the case, then that doesn't provide any protection is your database is compromised.

Or is it perhaps because if you are using token based authentication, you're either doing password grant type, which requires you to send your credentials along with the client id and secret, or a refresh token, so a user would have already had to have been compromised?

Answer 1

I can imagine a few possible answers to this:

• In some cases, it may be required for the server to have persistent storage of the plaintext API key in order to satisfy usability requirements (Google and Twitter being examples).
• In some cases, the API key alone is not enough to do much at all -- additionally one needs to have an authenticated account -- and therefore the API key by itself is of limited value (hence less value than a password).
• In a number of cases, the API key is hardcoded in a client application (especially mobile applications, which almost always do this) and therefore it does not make sense to add the extra protection on the server side when the same token can be trivially extracted from the client.
• The security industry is just not that mature yet. Maybe once hackers start dumping API keys, ideas like this may be taken more seriously.

BTW, I am very serious about the last point. The truth is that a lot of good ideas don't become a reality until there is a critical mass of support behind them. As an example, I once blogged about a related topic -- protecting user confidential information by hashing it in the database but in a way that it could be recovered when the legitimate user logs in. I used Ashley Madison as an example -- in that case, the hackers were more after email addresses, phone numbers, and physical addresses than passwords. So when the hackers snatched the database, they immediately had what they wanted, and they could care less about the bcrypt encoded passwords (in fact, some older passwords were encoded with only MD5!) Unfortunately, concepts like this do not have enough of a push to make them a reality. Even zero-knowledge web designs are very few in the real world.