Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Apr 2018 15:08:45 -0700
From: Jim Fenton <fenton@...epopcorn.net>
To: passwords@...ts.openwall.com, Arnold Reinhold <agr@...com>
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: keyed hash vs. encryption

Apologies for not responding sooner on this thread. I agree strongly
with the "belt and suspenders" approach (defense in depth) discussed
later on this thread: Use both a resource-intensive hash (+salt) and
either encryption or an additional hash with a secret key. That way, if
someone comes up with an exotic attack (rowhammer? side channel?) that
breaches the secret key, things aren't any worse than they are today.

One additional point:


On 3/22/18 5:40 PM, Arnold Reinhold wrote:
> 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?

Remember that SP 800-63 is only normative for the US federal government.
A lot of other organizations create their own standards and
recommendations based on it, and that's the best place to promote better
practices. Organizations like OWASP are good places to start. I'm not
involved in OWASP, but have had conversations with them about updating
recommendations such as their Password Storage Cheat Sheet
<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet>. The
Cheat Sheet does have a recommendation to leverage keyed functions.

I'm sure there are other organizations like that. Perhaps I should be
preaching this in an RSA Conference talk next week, but wasn't sure if
this was appropriate as a contractor (not a NIST representative).

-Jim



Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ