> 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.<p>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.<p>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.