Hacker News new | ask | show | jobs
by CiPHPerCoder 3394 days ago
Hashing is deterministic.

If you give the system m, you can probably deduce H(m). If you can send candidates m, m', m'', etc. and compare the timing information of H(m), H(m'), H(m''), etc. you can learn some information about the hash being stored.

This still probably isn't exploitable (you'd need a practical preimage attack, at a minimum), but you're still leaking some knowledge from the timing leak of the comparison of the candidate hash with the stored hash.

With a split token approach, the verifier is totally unknown to the attacker. You can generate a valid selector from observing timing observations... and that's it. Game over. Find another way in the system.

If you have a 128-bit random string as your inputs, this will probably never be guessed.

It's easier to reason about the security consequences of no leak versus a minor, probably impractical leak.
1 comments
tbrowbdidnso 3394 days ago
You can mix the hash with a salt that the attacker doesn't and cannot ever know. This is pretty standard and prevents the leak of timing from revealing anything about the hash. The only time this fails is if your hash function is broken, and if that's the case you've got much bigger problems
link
earthrise 3394 days ago
The salt would need to be kept secret so it shouldn't be called a salt, it should be called a key. The benefit of Scott's solution compared to this is that you don't need to deal with all the usability problems associated with keeping something secret (where should it be stored on the server? how should it be backed up? how often should it be changed? etc.)
link
CiPHPerCoder 3394 days ago
Hash it how, exactly? H(s || m)? HMAC(m, s)?

> The only time this fails is if your hash function is broken, and if that's the case you've got much bigger problems

Or if your salt is leaked.

A salt, by definition, is not a cryptographic secret. That's why they're stored (in plaintext) as part of the hash in every password hashing algorithm.

It sounds like you're advocating for an additional HMAC instead, with a secret key used to authenticate these messages instead of a salt. Which is fine.

But to call split tokens convoluted, then turn around and propose salted hashing the entire thing and still not solving the existence of the timing leak? I find this hypocritical, and oddly reminiscent of people who think it's fine to escape-and-concatenate to solve SQL injection when we've had prepared statements available for over a decade.

link