<div dir="ltr"><div class="gmail_extra">> NIST also recommends another layer of protection using a keyed hash with<br>> a secret key:<br>><br>> If you are going to make a salt secret and store it in an HSM, why not just<br>> encrypt the password and avoid all this costly memory hard hashing?<br>><br>> Salts were never supposed to be secrets, they exist to increase the cost of<br>> offline attacks, by preventing the use of precomputed rainbow tables.<br>><br>> Arguably with GPU based attacks, they are only adding a small increase in<br>> work, linear in the number of passwords to be cracked, if they are stored<br>> alongside the hashed password.<br>><br>> But again, if you have a good secret,  can you not just encrypt...?<br>><br>> 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.<br><br></div><div class="gmail_extra">Yes, and salts are still needed to prevent precomputed table attacks.  I think the point of massively parallel attacks is that, since they are online attacks (not precomputed), adding a salt into the mix is only adding a few bytes processing per hash.  In fact, this is probably more like a constant factor, e.g. twice as slow as no salt.  So they aren't really a factor in deterring those sorts of attack, but are still needed if there's no other good secret in the mix.<br><br>> 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.  <br><br></div><div class="gmail_extra">It's a nice defence in depth.  It just prompted me to wonder if I had a really good secret, would I need the rest of the password storage paraphernalia?<br></div><div class="gmail_extra"><br>For HSMs to be used for password hashing, there must be some way to clone the HSM and/or backup the secret key.<br> That secret then becomes a potential, and extremely valuable, target for attack. How much confidence should we place in ordinary enterprises protecting such secrets?  <br><br></div><div class="gmail_extra">I agree.  The HSM vendors have good solutions for all of these but they require processes and people and other controls to make them effective.  I have seen them done well, but only for highly critical applications.  Which is why maintaining really good secrets is expensive.<br></div><div class="gmail_extra"><br>> I gave a talk on this problem a year ago at BsidesLV16: <a href="https://www.researchgate.net/project/Rock-Salt">https://www.researchgate.net/project/Rock-Salt</a><br><br></div><div class="gmail_extra">Interesting talk, thanks.  I read about Rock-Salt a while ago, probably from something you mentioned here.  It's a really nice idea, because it creates something which is not easily exfiltrated, but with fewer of the HSM downsides.  Even if it's not *quite* as secure as a really well managed, and expensive, secret :)<br><br></div><div class="gmail_extra">Matt.<br></div><div class="gmail_extra"><br></div></div>