Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I need a password hashing function that is deterministic. Correlation attacks are not a concern. The same password must produce the same hash. I just want to protect the password against dictionary and brute force attacks in the event that the hash is leaked.
Is there a well known way to do this? Would fixing the salt of bcrypt/PBKDF2/scrypt be enough?
Yes, this is thought to be so.
The point of PBKDF2, scrypt & bcrypt is to produce the same output on the same input, otherwise they would be useless as key derivation function (KDF).
I personally prefer Argon2 since you can tweak it a bit more, it makes a better usage of RAM and computing time, etc. As explained on Wikipedia, PBKDF2 is not the best because it can be implemented on ASIC devices, which makes brute-force attacks using ASICs or even GPUs easier than for certain other KDFs.
Using a fixed salt for all entries just allows a dictionary attack against your specific application to be mounted, although this should still be somewhat hindered by the computational cost it would imply. That's not too worrying as long as you've generated the salt yourself and are not using a generic value (such as the empty one). But in general we never recommend using a fixed salt.
Instead, note that the good practice would be either to derive the salt in a deterministic way (from the username, for example), or to store the salt in the database next to the password (so that each password has a different salt.)
Note that the good practice would be either to derive the salt in a deterministic way (from the username, for example) That is a brilliant idea. Thanks!
$\endgroup$
Can PBKDF2 be used (as) a deterministic slow hash?
Only to give a false appearance of security. PBKDF2 (with HMAC-SHA-x as most implementation do) is technically obsolete and should no longer be used. When parameterized for convenient computation time on medium-speed device (say, a mobile phone or standard PC not assumed to have hardware-assisted hashing), it provides very little protection against adversaries using (hypothetical) ASICs made with technology similar to those used in bitcoin mining hardware, and not much against more modest adversaries using modern GPUs.
Would fixing the salt of bcrypt/PBKDF2/scrypt be enough?
With scrypt and appropriate parameterization, yes. Bcrypt would be much better than PBKDF2, but it shows it's age (the RAM size is fixed and low by modern standards, input length is limited and that's an issue with non-ASCII input, the results are non-portable across implementations, and some have serious bugs). The sate of the art is Argon2, winner of the Password Hashing Competition.
