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

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.

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.

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.

Regards,

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