[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64bdf739-2890-d914-824d-3a11057d2fb8@bluepopcorn.net>
Date: Wed, 8 Nov 2017 14:32:47 -0800
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com, Arnold Reinhold <agr@...com>
Subject: Re: Real world password policies
On 11/3/17 1:29 PM, Arnold Reinhold wrote:
>> On Oct 30, 2017, at 5:06 PM, Jim Fenton <fenton@...epopcorn.net> wrote:
>>
>>
> …
>> The approach is different for offline attacks: in addition to salting and iterated hashing with an expensive key derivation function, SP 800-63B recommends an additional keyed hash with the key stored separately (as in an HSM, or on a separate machine not otherwise accessible). So if the verifier can keep the key secret, the hashes aren't usable by password cracking at all.
>>
>> Additional guidelines on the size and composition of blacklists is planned for the implementation guide that is a companion to SP 800-63B, currently under development.
>>
> The NIST SP800-63B recommendation to hash password verification data using a key stored separately in some sort of protected hardware is a big step forward, but it comes at the end of a string of SHOULDs (vs SHALLs) in the document. I realize the guidelines are only a few months old, but is there any momentum, either in the U.S. Government or the private sector towards implementing that recommendation?
The recommendation to do an additional keyed hash with a key stored
separately is completely new in 800-63. While I'm convinced that's a
really good thing to do, I don't know if anyone who is doing it yet, and
making it a SHALL is a bit abrupt. We need to be mindful that there are
many authentication systems used by the government, and we can't
arbitrarily make some of them (perhaps based on commerical products)
suddenly out of compliance.
The specification doesn't actually call for a hardware implementation
(e.g., HSA) of this. A reasonable solution might be to stand up a
separate server, not accessible from outside, that accepts password
hashes and rehashes them with the private key. In my "spare time" I'm
working on a proof-of-concept for this that I plan to open-source.
Shouldn't take long.
>
> If the planned implementation guide could include a timetable for shifting away from using fast compact hashes by themselves (even with salt) for securing password data, we could begin to plug a major source of data compromise. NIST, after all, is responsible for the SHA series, and I would argue the naked use of those hashes to secure password data is akin to a harmful, off-label use of a drug that the FDA approved for other purposes. While such a strengthening of a guideline that just came out would be unusual, the recent White House Executive Order 13800, "Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure," could provide a strong imperative for such a move.
I'd stick with the hashes we have and just apply this keyed hash on top
of it, as a defense-in-depth measure. It's of course still important to
have the salt so that duplicate passwords in the database don't result
in duplicate hashes.
>
> Another thing that would help in the implementation guide is an approved algorithm for encapsulating existing password hashes in a stronger hash. This is not particularly difficult bit of coding, but have a specified, thought-through, algorithm would facilitate upgrades of many organization’s password security.
I don't remember have seen any NIST specification for the existing hash
encapsulations, but I see this as just a change in the name of the
algorithm. So if the existing hash entry is something like:
pbkdf2_sha256$30000$s1Gothp198ob$4vkE1p+ktDq5UvUGKpIpoxX/qOhLEa2+srloFdsbhkE=
it might now be something like:
pbkdf2_sha256_rehash$30000$s1Gothp198ob$4vkE1p+ktDq5UvUGKpIpoxX/qOhLEa2+srloFdsbhkE=
(of course with the hash value changed).
But this is largely an internal issue to the verifier. We want it not to
"share" the hash, after all!
>
> I would also like to see a recommendation for disclosure of the password data security levels that a password-secured resource employs, e.g. use of salt, resource intensive hash, hardware keying. This would allow users to choose more manageable passwords on better secured sites and would create competitive pressure to do the right thing.
Interesting idea. While we want to improve password security as we can,
we really want to have users/sites go to multifactor authentication for
anything with non-negligible risk. Requiring disclosure of password
security measures might make people too comfortable with passwords.
>
> I realize you don’t speak for NIST, but if there is any way we can help move this forward, please let us know.
Thanks; appreciate your ideas.
-Jim
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
