4 ms·
No. Semantically these are very different objects/concepts Passwords: - tightly couple authentication (I am kortex) and authorization (I can do everything lo
by kortex 5y ago
No.
Semantically these are very different objects/concepts
Passwords:
- tightly couple authentication (I am kortex) and authorization (I can do everything logged-in kortex can do)
- not meant to be rotated unless breached (forced password rotation mandates weaken passwords, imho)
- are passwords meant for human transport, if even briefly
- hard to revoke (once expired, still valid until user rotates)
- usually insufficient entropy, dependent on user habits
- one flavor: a secret string
Tokens:
- decouple authentication and authorization
- ephemeral
- revokable
- enable automatic rotation (session tokens vs auth tokens)
- can have metadata
- as much entropy as you want
- many flavors
- ezekg 5y agoGive me a break -- we're just arguing semantics at this point. My whole premise was that tokens are a secret, just like passwords are a secret, and that tokens should be treated like a first-class secret. Not that they're absolutely "the same." The article gives the illusion that Simple Random Tokens are safe to store as plain text. I was arguing that it's not, and that the token should be ran through an HMAC function at the very least to prevent plain text storage and to harden against timing attacks when querying. Nowhere was I implying that passwords and tokens are strictly identical in all aspects. I've worked at places where tokens are stored in plain text (i.e. almost everywhere I've worked) and it's a bad practice.
- sbierwagen 5y agoPasswords are hashed because users constantly reuse them between sites. If they didn't do that there would be no reason to hash them.
- ezekg 5y agoNo, passwords are salted because they are reused...
- tptacek 5y agoThis is not true at all. This whole discussion is pretty confused. All of the mitigations we apply to passwords are premised on passwords being (1) cryptographically weak, (2) irrevocable, and (3) infectious to other systems. Nerds are, for reasons I will never understand, hyperfixated on "salting". Randomized password hashes primarily address an old attack that is more or less irrelevant to any modern hash or KDF. But that attack, too, mattered because (1), (2), and (3) hold for passwords.
- kortex 5y agoI thought salting+hashing was primarily to mitigate damage in an event of someone scooping the credentials data store. And/or bruteforcing. If there were one login system/site in the whole world, you'd still want to hash/encrypt them. I mean hashing is one of the easiest things to do to add a layer of security, so even if the db is encrypted, why not? Maybe I'm missing your point.
- kortex 5y agoAh ok I see what you are saying. My bad. Totally agree with your main point of "tokens, like passwords, should be kept discrete."
- tptacek 5y agoTokens are secrets. Passwords are secrets. Ed25519 private keys are secrets. We hash passwords. Thus we must hash tokens. Should we therefore hash our Ed25519 private keys?
- ezekg 5y ago> Should we therefore hash our Ed25519 private keys? No, but I'm of the opinion that you should encrypt private keys before storing them in a database.
- some_furry 5y agoIsn't there a weird attack possible with publishing SHA512 hashes of Ed25519 private keys that Signify barely side-stepped?