[UncleMeat]

> 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?

[xyzzy123]

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.

[Cpoll]

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.