I have passwords stored in my database that are very long, unique and generated by a CSPRNG.

Do I need to use a salt before hashing them?

My understanding is that usually you use a hash function in the following way:

hash(salt + password)

where the + is simply the concatenation of the 2 strings (or byte arrays). Since my passwords are already randomly generated, it's useless to prefix them with a salt which is another random value.

  • 1
    "Do I need to use a salt before hashing them?" No
    – user49075
    Aug 12 '14 at 3:21
  • How did you seed the CSPRNG? If its seeded with user input, you should add a salt, because the seed could be dictionary attacked to generate a list of equivalent CSPRNG outputs. Aug 12 '14 at 3:38
  • 2
    To extend @Jeff-InventorChromeOS's point, how much entropy does the password have (taking into account the seed's entropy, output size, etc)? If it's high enough to make password-guessing attacks completely (and I mean completely) impractical, then seeds don't matter. Aug 12 '14 at 4:08
  • The password have as much entropy as the salt would have as they are generated with a CSPRNG. The server decide them then they are assigned to a user. Of course they are long enough to make brute force impractical.
    – Gudradain
    Aug 12 '14 at 11:39
  • Nobody else has mentioned this yet, but H(salt + password) is not a sound password-hashing scheme. If all of the passwords have high-enough entropy (e.g., 128+ bits) then H(password) is fine for any strong hash function. If any of the passwords are user-created, use bcrypt or scrypt. These implement known-good password hashing algorithms and abstract away details like salts. Dec 2 '14 at 18:56

The purpose of salting when hashing passwords is to prevent identical passwords from resulting in the same hash values. If your passwords all are, as you say, long and generated by a CSPRNG, then you will not have identical passwords in your database for different users; they will all be unique, and salting adds nothing to the security of these passwords.

However, there may be a caveat. And that is, if you have some passwords that are non-random. I.E., if the random passwords you generate are initial passwords, but users have the ability to choose a different password. If this is the case, then you should more certainly salt your passwords, including the randomly generated ones. There are two reasons for this.

  1. Adding branching logic to salt some passwords but not others is unnecessary complexity, and unnecessary complexity is expensive and evil. By salting everything you're neither reducing nor increasing the security of the random passwords, but simplifying the application logic and reducing the chance for bugs, security or otherwise.

  2. This could drastically reduce the security of the non-random passwords. If your scheme is known and the hashes and salts are extracted by an attacker, they will immediately be able to determine which passwords (the salted passwords) are not random generated, and should be attacked. If all passwords are salted, the random passwords will be indistinguishable from the user-defined passwords.

  • Using an alphabet of [A-Za-z0-9], there are 62 different characters, and randomly picking 8 of these, that makes 218 trillion combinations. If I have only a million or so users, the odds of a collision, even without salting, is 1 in 200 million. In such a case, can I safely not bother with hashing and salting? Apr 30 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.