I have seen a few answers here and elsewhere that say a salt doesn't need to be cryptographically secure randomness but rather just unique since they are stored in the open anyway. I am working on an implementation of PBKDF2 and AES-CBC and reading NIST SP 800-132 Recommendation for Password-Based Key Derivation from 2010, it states in section 5 regarding salts:

All or a portion of the salt shall be generated using an approved Random Bit Generator (e.g., see [5]). The length of the randomly-generated portion of the salt shall be at least 128 bits.

I don't personally care whether it needs excellent randomness or not but I just want to get it cleared up for my own sake whether the NIST recommendation contradicts that salts don't need to be cryptographically secure.


1 Answer 1


In cryptography books, a salt is defined as a random value, but it technically only needs to be unique. See, for instance, the Argon2 RFC:

The salt SHOULD be unique for each password.

The reason CSPRNGs are used is because they generate unique values with negligible chance of collision if you request a large enough output (e.g. 128 bits). By contrast, regular PRNGs and other strategies (e.g. a username or full name) may be predictable and/or lead to repetition.

Therefore, if you want to randomly generate salts, they should be cryptographically secure. If you can't use random salts (e.g. a deterministic password manager), a non-cryptographically secure salt is fine as long as it's unique.

  • 1
    $\begingroup$ Thanks for the answer. I will take this that salts don't need to be cryptographically secure. $\endgroup$
    – mirkaim
    Oct 24, 2022 at 0:42
  • $\begingroup$ That's correct, although you should use a CSPRNG for random salts. I will clarify my answer slightly. $\endgroup$ Oct 24, 2022 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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