Permitting the hash to leak via a timing attack changes the available defenses. Online guessing attacks are fundamentally slower (go too fast and it’s indistinguishable from a DoS), which practically limits their guessing rate. Allowing the hash to leak via a timing attack means the attacker can perform an offline guessing attack.
I agree in principle with the preceding answer that with a sufficiently large random salt which isn’t leaked (say, 100 bits or so), offline attacks against the hash become infeasible.
However, I prefer in principle to encourage never leaking user password verifiers. Attacks only get better; why let the attacker have data which it is trivial to keep from them by using a standard constant time comparison?
Also, it saves the bother of checking if your salt is lon…
Permitting the hash to leak via a timing attack changes the available defenses. Online guessing attacks are fundamentally slower (go too fast and it’s indistinguishable from a DoS), which practically limits their guessing rate. Allowing the hash to leak via a timing attack means the attacker can perform an offline guessing attack.
I agree in principle with the preceding answer that with a sufficiently large random salt which isn’t leaked (say, 100 bits or so), offline attacks against the hash become infeasible.
However, I prefer in principle to encourage never leaking user password verifiers. Attacks only get better; why let the attacker have data which it is trivial to keep from them by using a standard constant time comparison?
Also, it saves the bother of checking if your salt is long enough, and saves you if later someone decides the salt was too long and shortens it for newer hashes, etc. Constant time comparison should be uncontroversial. Why not do both? Do the extra microseconds of comparison time really matter? (Did you profile your code before wanting to optimize that away?)