
Why access and API tokens are the new passwords but worse - akane
https://emilebosch.com/2018/10/06/why-acess-tokens-are-the-new-passwords-but-worse/
======
Cpoll
> 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.

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

------
toyg
Poor post (not even spellchecked) about an actual but well-known problem.

------
Arzh
This might be one of the worst things I've read this week. Tokens shouldn't
have anything to do with your login and giving out login is so much worse.

~~~
akane
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.

~~~
Arzh
Why would I want the access tokens to be revoked if I change my password,
unless I revoke the token it should be valid.

------
PaulHoule
That call to action at the bottom is awful.

