[Cryptography] NIST SP 800-63-3

[Matt Palmer]

> 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...?
>
> 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.

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.

> 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.

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?

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 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.

> I gave a talk on this problem a year ago at BsidesLV16:
https://www.researchgate.net/project/Rock-Salt

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 :)

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