I chose the words "password hash" carefully. If you're using a secure password hash, you're not worrying about salts, because they take care of randomization for you. If you are worrying about salts, you probably have bigger problems than memcmp timing.
I literally don't understand what it is you're getting at.
Password hashing has existed since at least the 1970s and until the 2000s salting wasn't common. While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage.
Therefore it is still common for an application developer to "worry about salts" even if just for storage and generation reasons.
Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash." Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
"Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you.
> Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in the realm of a "password hash."
3DES is a block cipher. MD5 is a crytographic hash. Neither of them are password hashes.
> Plus some wonderful developers hard code the salt (salt = "secret") which too could leave them vulnerable to timing attacks if an attacker knew what hashing algorithm and workfactor (e.g. the default) was in usage.
> 3DES is a block cipher. MD5 is a crytographic hash.
3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar.
> Neither of them are password hashes.
25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years.
But no doubt you'd playing silly word games, and are going with your own definition of "password hash" that includes or excludes different hashing algorithms as it is convenient for you. I won't get drawn into that.
> What you're describing is closer to a "pepper".
What you're doing is called being "condescending." You know full well from my posts above that I am familiar with salt/peppering/hashing, and the different technologies involved. So linking to 101 tutorials and definitions of basic terms is only intended to aggravate.
I think everyone is getting a little to emotionally invested here. Might be a good time to take a step back and detach a bit. Apologies for interrupting your conversation, I just don't like seeing everyone going for each other's throats on HN.
To be honest I'd probably interpret them as being antagonistic if the same statements were directed at me (and quoting never helps either) but I think if you take a charitable interpretation it doesn't read that way. I think it's just a direct/technical challenge/debate sort of reply and it's really easy to read into those when you're on the receiving end of them.
> While some hashing libraries do insist on you supplying a salt, it is still ultimately up to the application developer to generate and store the salt for later usage.
If your password storage mechanism requires you, the programmer, to generate a salt, you may well be using the wrong password storage mechanism, or using it in the wrong way.
