[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEqjJ7ARjQJ=qBvt5YkVrntnu7=AbO_b74z0dE-C1EEosuf=pw@mail.gmail.com>
Date: Fri, 23 Mar 2018 06:37:55 -0400
From: Willard Dawson <willard.dawson@...il.com>
To: passwords@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>, Jim Fenton <fenton@...epopcorn.net>
Subject: Re: keyed hash vs. encryption
Your comments resonate with my own recent thoughts, Arnold. At work, when
giving feedback to system designs involving 3rd party who is using a
reasonably secure hashing format, where do we ($dayjob) draw the line at
what is minimally secure password complexity requirements? As you say, "it
depends," on the hash format, on available computing power at any given
time. The best we can hope to do is get a "reasonable" set of rules there.
Problem is, security teams at most companies will stop well short of a
meaningful policy, putting everyone affected at increased risk. The
tolerance for truly complex passwords is nowhere near where it needs to be,
and never will be. Humans are mostly incapable of it. A meeting might help,
but I think it will ultimately come down to the perceived risk vs. cost,
and that discussion has to happen near enough to the top of organizations
where such budgets are approved. Problem is, that discussion often leads to
"we've not been hacked yet, so why spend extra money on a problem we'll
pretend we don't have?"
On Thu, Mar 22, 2018 at 8:40 PM, Arnold Reinhold <agr@...com> wrote:
> 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
>
>
--
Willard Dawson
(678) 230-3461
willard.dawson@...il.com
Content of type "text/html" skipped
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.
