Please, don't use equality operator when comparing password hashes

nowhereref.com

3 pointslogronoide3 comments

This article seems confused. To successfully execute a timing attack against the hash equality comparison, an attacker would need to be able to generate passwords hashing to arbitrary chosen prefixes, which means that your hash function is super broken.

Agreed, in a properly done system as described password hashes shouldn't really be exposed to this, so it's a marginal improvement at best.

Where it is important is cases where the attacker directly supplies the hash: e.g. protocols where the password hashing is done client-side, or HMACs securing tokens and things like that.

I wonder if there is any ecosystem that tries to nudge to this using the type system, e.g. having hash functions return a "HashString" type that will use constant-time comparison functions by default, and needs to be explicitly unwrapped if you want to turn it into a normal string type.

Out of curiosity, if you were to write a constant time comparison that always compares every byte, will some compilers just optimize that away and replace it with something that returns false on the first unequal byte?

Reply on news.ycombinator.com