[Cryptography] NIST SP 800-63-3

[Arnold Reinhold]

On Fri, 11 Aug 2017 17:22 Matt Palmer asked:

>> NIST also recommends another layer of protection using a keyed hash with
> a secret key:
> 
> 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?
> 
> Salts were never supposed to be secrets, they exist to increase the cost of
> offline attacks, by preventing the use of precomputed rainbow tables.
> 
> 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.
> 
> But again, if you have a good secret,  can you not just encrypt...?
> 
> Regards

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.

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: https://www.researchgate.net/project/Rock-Salt <https://www.researchgate.net/project/Rock-Salt>

Arnold Reinhold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170812/f5542574/attachment.html>