# Can pbkdf2 be used with a fixed salt to give a deterministic slow hash?

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! Jul 16 '17 at 16:15
• If you are feeling paranoid you may also use an additional "pepper" as describe in that answer to have an extra layer of security.
– Lery
Jul 16 '17 at 16:29

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.

• I both agree, since PBKDF2 is not really the state of the art in term of password-hashing, but also disagree when you say "PBKDF2 (with HMAC-SHA-x as most implementation do) is obsolete and should no longer be used", do you have references regarding the fact it's really obsolete? I still see it recommended by NIST here and personally don't consider it to be avoided yet. But I'd be happy to revise my judgement if you had some more food for thoughts for me.
– Lery
Nov 27 '20 at 17:32
• @Lery: PBKDF2 is technically obsolete, and it's a shame it's not declared so by authorities that purport to give sound recommendations (I don't attribute to malice or incompetence what can be explained by disorganisation, but this is fuel for conspiracy theories that NIST has a split personality when it comes to crypto security). My reference is linked in the answer: an ASIC device nowadays hash at >100 TH/s for <\\$3000 and <4kW (where hash is SHA256d, comparable to HMAC-SHA-256). At 1M HMAC-SHA-256 (considered a lot in PBKDF2), that would be 100M password-to-key transformations per second!
– fgrieu
Nov 27 '20 at 17:44