Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc394cfe-b195-a4ba-708b-70bffc8d43a6@bluepopcorn.net>
Date: Thu, 7 Dec 2017 14:54:21 -0800
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com
Subject: Re: Real world password policies

On 11/8/17 2:32 PM, Jim Fenton wrote:
> 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.

To close the loop on this, I have published a simple utility for doing
this. The code is at

https://github.com/jimfenton/rehash

and I have described it further at

https://altmode.org/2017/12/05/protecting-passwords-against-cracking-with-rehash/

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