Am I using RfcDeriveBytes correctly, when the salt I'm providing it contains the password?

Question

I'm using Rfc2898DeriveBytes in my application to encrypt a password with a randomly generated salt, and with a set iterator count for slowness.

Before, I just grabbed the generated salt and put it as a parameter for Rfc2898DeriveBytes to take care of, but now I've changed my approach to the following, and I'm wondering if it's doing more good, or more bad:

1. Generate a random salt.
2. Append the password to the salt.
3. Hash the salt, using SHA-512.
4. Pass the hashed salt to Rfc2898DeriveBytes, so it can do its magic.

I'm aware that any salt I provide to Rfc2898DeriveBytes, as long as it's unique/randomly generated, is considered a "true" salt, due to the nature of how the method operates. Does that mean that it'd be just as good as to pass the generated salt without any of the above modifications? (appending the password to it, and hashing it)

For informational purposes, the hashing algorithm Rfc2898DeriveBytes uses, is SHA512.

Answer 1

Nope, that's very much not a good idea. Just using the random salt from your step #1 is likely good enough. Section 4.1 of RFC 2898 provides recommendations for how to generate salts; the additional suggestion they make is that some applications will want to also have associated data pertaining to the encryption/decryption context.

The problem with using the password as an input to salt generation is that salts need to be independent of the password. Password crackers work off a base of knowledge about how users pick passwords, embodied in things like huge password dictionaries. The purpose of salts is to prevent attackers from using this knowledge to precompute any sort of table that allows them to speed up their cracking once they do manage to steal a password database. In the degenerate case where the password serves also as the salt, this goal is completely negated—the attacker can use their knowledge about common passwords to precompute each one's corresponding salt as well.

The fact that you incorporate both a random value (your step #1) and the password (step #2) in synthesizing your salts probably defeats such an attack, but the random salt from step #1 is already sufficient to do so; incorporating the password into salt generation is only playing with fire.

Answer 2

Why is using the password as part of the salt a problem?

Because you need to store the salt separately from the hash of the password. You can either do this by encoding them in a specific way, such as storing them as $Rfc2898$iterations$mysalt$myhash or by using dedicated database tables.

If you would go with the scheme you proposed (crating a random salt, appending the password and hashing it with SHA-512), then an attacker would not need to crack the 100000 rounds of PBKDF2 at all. Why? Because you provided them with what is essentially SHA-512(password, salt). The fact that you later use this data as input for a more computationally expensive form of hash doesn't matter, because you need to save this data for further verification?

But what if I just save the random part of the salt and then mix the user input in on-the-fly?

Yes, you just proved that mixing in the password gives you no security gain whatsoever. All you need is the random part!