<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><br>>>> NIST also recommends another layer of protection using a keyed hash with a secret key:<br>>><br>>> If you are going to make a salt secret and store it in an HSM, why not just encrypt the password and avoid all this costly memory hard hashing?<br>>> Salts were never supposed to be secrets, they exist to increase the cost of offline attacks, by preventing the use of precomputed rainbow tables.<br>>> Arguably with GPU based attacks, they are only adding a small increase in work, linear in the number of passwords to be cracked, if they are stored alongside the hashed password. <br>>> But again, if you have a good secret,  can you not just encrypt...?<br>><br><div dir="ltr"><span class="gmail-"></span><div class="gmail_extra">>With encryption, if the secret key gets compromised, then its as good as having plain text passwords. With keyed hash you will still need to have some resources to crack it.</div></div><div><br></div><div></div><div>The general threat is offline cracking on a password file or database.  The response so far has been to increase the cost to an attacker via hashing, salts, iteration and memory hard functions. They are all fairly cheap for the defender to implement, and do not require expensive secrets to be managed.<br><br></div><div>Once we have an encryption key stored in an HSM, the offline cracking threat goes away unless the attacker can also physically steal the HSM.  It should be quite hard to extract a key from a properly designed HSM, leaving brute force attacks calling the HSM API.<br><br></div><div>I completely agree that having both provides defence in depth, but I'm not sure both are required once we have a properly managed secret.  I think I would be comfortable with just an encrypted password with a key stored in an HSM.<br><br></div><div>Regards,<br><br></div><div>Matt<br></div><div><br></div><div><br></div><div><br><br></div><div> </div></div><br></div></div>