undefined | Better HN

0 pointskoolba10y ago0 comments

That's still broken. They've just pushed the problem deeper. Now instead of having a timing attack on the number of operations in the compare, the timing attack is pushed to the number of bytes that is hashed by sha256. Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

0 comments

zaroth10y ago

This is considered best practice for languages where you can't trust your "constant time" comparison won't be optimized out from under you.

Performing a timing attack requires control of the bytes being compared. If you can control the bytes of the output of a SHA256 then there are some Bitcoin miners who will pay you a lot of money.

If you want to be over-the-top about it you can get some secure randomness and add it to the values being compared before hashing, and then attacker would have even less control over the bytes being compared.

jmgao10y ago

You don't need to control every byte for this to be catastrophic. You can't decode every password like you can with the previous comparison, but if you can generate a rainbow table that contains the password you're trying to crack, you can just do a timing attack using the hashes instead. My intuition is that this might even require fewer attempts than the original comparison assuming a reasonable password length, but I haven't done the math.

ryanlol10y ago

I suppose you could theoretically deduce a large enough part of the hash to perform a bruteforce attack though.

You don't need that much of the hash to perform wordlist attacks and find likely candidates.

zaroth10y ago

Yes, this is true if you are talking about unsalted passwords, or if the attacker knows the salts. If there's an unknown salt, having the salted hash of a given plaintext input match the first few bytes of the target salted hash does not help you narrow the word list at all. If there is no salt, or the salt is public, then that's a case where you could append some ephemeral CS-PRNG output to both sides before hash-comparing... but probably better to fix the underlying issue.

I mean, it's funny to be far enough down the rabbit hole to be doing hash-compare. Then to say we wanted randomly keyed hash-compare is the final step. The nice thing is adding some random bytes imposes a fairly miniscule performance hit and it's purely computation, no additional storage. Probably still too slow to use for every comparison, but for constant-time critical comparison, it literally can't hurt.

ryanlol10y ago

>Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

Hash collision implies attacker has control of both the inputs, in this case we'd be talking about a preimage attack.

If your attacker can perform preimage attacks on SHA256 they can also most likely hack you via your package manager.

j / k navigate · click thread line to collapse

0 comments

zaroth10y ago

This is considered best practice for languages where you can't trust your "constant time" comparison won't be optimized out from under you.

Performing a timing attack requires control of the bytes being compared. If you can control the bytes of the output of a SHA256 then there are some Bitcoin miners who will pay you a lot of money.

jmgao10y ago

ryanlol10y ago

I suppose you could theoretically deduce a large enough part of the hash to perform a bruteforce attack though.

You don't need that much of the hash to perform wordlist attacks and find likely candidates.

zaroth10y ago

ryanlol10y ago

>Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

Hash collision implies attacker has control of both the inputs, in this case we'd be talking about a preimage attack.

If your attacker can perform preimage attacks on SHA256 they can also most likely hack you via your package manager.

j / k navigate · click thread line to collapse