[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <636B9D41-835F-4D60-8C3D-A0DA824B6B9C@me.com>
Date: Thu, 22 Mar 2018 20:40:57 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>, Jim Fenton <fenton@...epopcorn.net>
Subject: Re: keyed hash vs. encryption
On Mar 16, 2018, at 9:49 AM, Solar Designer <solar@...nwall.com> wrote:
>
> On Fri, Mar 16, 2018 at 02:59:39AM -0700, Jim Fenton wrote:
>> On 3/15/18 1:08 PM, Solar Designer wrote:
>>> Now in another thread, Arnold argues in favor of changing the SHOULD to
>>> SHALL, and you haven't objected yet:
>>>
>>> http://www.openwall.com/lists/passwords/2018/03/15/1
>>>
>>> So I feel I have to: please either leave it at SHOULD, or please allow
>>> the hash encryption approach as an option as well (primary option even?)
>>
>> "yet"? I didn't realize there was a deadline.
>
> Of course, there was not, and by "yet" I meant precisely that you still
> could comment if you wanted to, which you did now - thanks!
>
>> SP 800-63B was published last summer after considerable public comment
>
I recognize that NIST SP 800-63 is final and not likely to be revised for some time. I was never suggesting that SHOULD be changed to SHALL immediately, rather that guidance be given that this is expected to happen in the future, at least for high value uses. That may be too simplistic. As this thread shows, there are still issues that could require resolution. As was pointed out, the “additional iteration of a key derivation function” language in 63b may unnecessarily restrict solutions. In particular the processing time savings in using a simple hash protected by a hardware secret vs using an open resource-intensive hash could be important in making the switch to an HSM scheme more attractive economically.
I’d like to hear the case for continuing to use an open hashing schemes to protect passwords long term. Given the massive growth in computing power associated with GPUs, crypto mining and botnets, is it realistic to expect any open KDF to protect a user-selected 8 character password (the 63b minimum)? At the least, one would need guidelines on the minimum work factors needed (iteration count and memory) that would increase over time.
In 2014 I had to increase the recommended size of a Diceware passphrase from 5 to 6 words. Five words were already more than most users find acceptable. As 63b says, with hardware secret password hashing “brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.” Enterprises should not keep burdening the user to solve a problem that the enterprise itself could solve with the right technology.
Resource intensive hashes will still be needed for applications such as disk encryption, master passwords for password managers, and for securing smaller systems. But for logging into large IT systems, given that we have a solution that can end the password arms race, it’s time to move forward. What do we have to do to facilitate that process? A meeting perhaps?
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.
