Yes, this is true if you are talking about unsalted passwords, or if the attacker knows the salts. If there&#x27;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&#x27;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.<p>I mean, it&#x27;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&#x27;s purely computation, no additional storage. Probably still too slow to use for <i>every</i> comparison, but for constant-time critical comparison, it literally can&#x27;t hurt.