[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <4F7266A1-DCEF-4E92-AB4C-64019919496F@me.com>
Date: Fri, 03 Nov 2017 16:29:50 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies
> 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?
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.
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 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.
I realize you don’t speak for NIST, but if there is any way we can help move this forward, please let us know.
Arnold Reinhold
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.
