> On top of that, passwords are at least hashed in the database and salted. And most frameworks promote this good behaviour nowadays and have extensive documentation on how to do this. But for API tokens we’re outta luck. We need them in their current plaint-text form to communicate with the API’s so all we can do is encrypt them at rest and decrypt them when necessary. Alas for many this practice is not widely communicated nor documented.
Half the reason to hash and salt is to prevent an attacker from obtaining the plaintext (often reused) password, which doesn't apply for API keys.
With that said, there's no reason why a service couldn't send you a plaintext API key but only store the hashed and salted key in their database. I suspect AWS, for example, does just that (you can't obtain your API secret except right after generating it). The API consumer needs a way to store/decrypt the plaintext API key, but that also applies to passwords.
> Half the reason to hash and salt is to prevent an attacker from obtaining the plaintext (often reused) password, which doesn't apply for API keys.
That's more than half of the reason. Do you really want to rely on an attacker only getting the password database from a breach and nothing else and then not spending the time to reverse the hashes?
Hm, I might be writing at cross purposes (I think you were addressing passwords?), but:
API keys are quite different from passwords and it makes sense to store and secure them differently.
If your site is generating API keys then you should ensure that they are say 128 bits of high quality entropy and use a fast hash.
Nobody is going to invert that, even if you use a single round of SHA-256 / HMAC / whatever.
It’s a good thing too because API keys need to get validated on every request and you wouldn’t want to use a heavy function (tens of millis like a decent kdf) on every request.
Okay, that's the entire reason, I meant to say that there's two facets of it: You don't want to jeopardize your users who reuse passwords, AND you don't want to make it easy for someone to login after getting your hashed and salted passwords.
The post doesn't say you should give out your login. It says you should encrypt your access tokens and explains some security implications of current implementations that use them, like how they often give too broad permissions. When you change your password, you often need to reauth all of your devices, but you don't need to reauth your access tokens.
Half the reason to hash and salt is to prevent an attacker from obtaining the plaintext (often reused) password, which doesn't apply for API keys.
With that said, there's no reason why a service couldn't send you a plaintext API key but only store the hashed and salted key in their database. I suspect AWS, for example, does just that (you can't obtain your API secret except right after generating it). The API consumer needs a way to store/decrypt the plaintext API key, but that also applies to passwords.