<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On Fri, 11 Aug 2017 17:22 Matt Palmer asked:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">NIST also recommends another layer of protection using a keyed hash with<br class=""></blockquote>a secret key:<br class=""><br class="">If you are going to make a salt secret and store it in an HSM, why not just<br class="">encrypt the password and avoid all this costly memory hard hashing?<br class=""><br class="">Salts were never supposed to be secrets, they exist to increase the cost of<br class="">offline attacks, by preventing the use of precomputed rainbow tables.<br class=""><br class="">Arguably with GPU based attacks, they are only adding a small increase in<br class="">work, linear in the number of passwords to be cracked, if they are stored<br class="">alongside the hashed password.<br class=""><br class="">But again, if you have a good secret, can you not just encrypt...?<br class=""><br class="">Regards</blockquote><br class=""></div><div class="">First of all, with millions of password hashes released in data breaches, "linear in the number of passwords to be cracked” is no small thing. A factor of a million reduction in attack rate due to the simple expedient of using salt is equivalent to increasing each password’s entropy by about 20 bits, which can be the difference between a password complexity that people might employ and requirements that are too onerous for most users. But as you point out, salt also makes rainbow tables infeasible and rainbow tables offer a speedup much larger than a factor of a million for vast numbers common passwords, allowing passwords hashed into the table to be recovered in seconds.</div><div class=""><br class=""></div><div class="">I don’t know NIST’s reasons for suggesting memory hard hashing be used along with a secret hashing key, but it could make sense as a belt-and-suspeners layered defense. For HSMs to be used for password hashing, there must be some way to clone the HSM and/or backup the secret key. That secret then becomes a potential, and extremely valuable, target for attack. How much confidence should we place in ordinary enterprises protecting such secrets? I gave a talk on this problem a year ago at BsidesLV16: <a href="https://www.researchgate.net/project/Rock-Salt" class="">https://www.researchgate.net/project/Rock-Salt</a></div><div class=""><br class=""></div><div class="">Arnold Reinhold</div><div class=""><br class=""></div></body></html>