2
$\begingroup$

NIST recommends doing an additional round of hashing using a secret salt:

In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.

Questions about this:

  1. Is it safe to ignore this advice? Are there any known vulnerabilities if we don't do this additional iteration?

  2. How should we implement this additional iteration, if the secret salt must be stored separately but need to be available when hashing a password? Should we use a dedicated server for the secret salt, transferred to the verification server using a secure protocol? The secret salt may stay in the verification server's memory, does this matter?

Improve this question
$\endgroup$
1
  • $\begingroup$ General practice is to save the salt with the verifier. But we also know that it is not completely secure, a risk that is generally accepted. $\endgroup$ Commented Jul 12, 2018 at 21:21

2 Answers 2

Reset to default
3
$\begingroup$

NIST document section 5.1.1.2 Memorized Secret Verifiers.

That section is a "SHOULD" not a "SHALL".

It is standard practice not to keep the salt secret but to save it with the password hashed verifier.

If the salt is not secret a brute force search is possible if the password is weak such as being on a list of frequent passwords. One example source of such frequent passwords is SecLists.

If the salt is secret such a brute force search will not succeed. Note: stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module) and such a device is generally not available.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ A little more specifically: the brute force search must guess the salt too, not just the password. Passwords may be chosen by humans (which is a bad idea, but people do it anyway, like driving cars), but random salts, one hopes, are chosen uniformly at random by computers, and as such are much harder for an adversary to guess. $\endgroup$ Commented Jul 14, 2018 at 21:28
0
$\begingroup$

A secret salt would solve the problem of crackable passwords, which are the majority of the password. You could set aside all the time-consuming and memory-intensive password hashing schemes designed to prevent dictionary attacks and custom hardware attacks - provided the salt is randomly generated and long enough.

However, in most cases a secret salt is not practical: you must keep it secret, but must be available for password hashing. Instead of a hardware security module, you could probably store it on a USB device, similar to key files like for VeraCrypt or TrueCrypt. But I have never seen such an implementation and I doubt users would use it.

If you can really keep a secure and unique salt secret, you do not need a password and there is no reason to use password hashing scheme at all.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Provided the salts are randomly generated and long enough. A shared salt leaks if two users have the same password. If you find a password database dump, identify which users have identical passwords, and focus your attention on the largest group, then chances are pretty good you have made for yourself a list of accounts with the password "Password1". Use all the groups, a list of common passwords, and then you can hijack hundreds or thousands of accounts using online dictionary attacks. No hashing required. $\endgroup$ Commented Jul 14, 2018 at 23:02
  • $\begingroup$ Secret password hashes, instead of secret salts, also solves the problem of crackable passwords. That assumption failing, however, is the reason password cracking is a thing. $\endgroup$ Commented Jul 14, 2018 at 23:04
  • $\begingroup$ Of course the salt must be unique for each password... $\endgroup$ Commented Jul 15, 2018 at 9:15

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.