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

Passwords are hashed because users constantly reuse them between sites. If they didn't do that there would be no reason to hash them.

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

No, passwords are salted because they are reused...

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

Ah ok I see what you are saying. My bad.

Totally agree with your main point of "tokens, like passwords, should be kept discrete."

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

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

What about the key that decrypts the private keys?

Encrypt that one too! Chelonia all the way down.

Isn't there a weird attack possible with publishing SHA512 hashes of Ed25519 private keys that Signify barely side-stepped?