[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e901184-0caa-b962-e692-21bc2962d638@bluepopcorn.net>
Date: Fri, 16 Mar 2018 01:22:18 -0700
From: Jim Fenton <fenton@...epopcorn.net>
To: Arnold Reinhold <agr@...com>, passwords@...ts.openwall.com
Subject: Re: Submitting Partial Password Hashes to Pwned Password
Lookup
On 3/15/18 9:24 AM, Arnold Reinhold wrote:
> NIST SP800-63B says (Par. 5.1.1.2): “In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier. This salt value, if used, SHALL be generated by an approved random bit generator [SP 800-90Ar1] and provide at least the minimum security strength specified in the latest revision of SP 800-131A (112 bits as of the date of this publication). The secret salt value SHALL be stored separately from the hashed memorized secrets (e.g., in a specialized device like a hardware security module). With this additional iteration, brute-force attacks on the hashed memorized secrets are impractical as long as the secret salt value remains secret.”
>
> That is a big step in the right direction, but I think setting a roadmap to requiring such measures (SHALL instead of SHOULD) must be the priority. SP800-63 already defines levels of security. I don’t know to what extent Jim has the ear of NIST, but setting level-specific deadlines for switching the Federal government to hardware-protected secret hashing of password validation data would seem a no-brainer. It would seem very much in line with last May’s executive order on cybersecurity https://www.whitehouse.gov/presidential-actions/presidential-executive-order-strengthening-cybersecurity-federal-networks-critical-infrastructure/
While I obviously feel strongly about improving storage of memorized
secrets by verifiers, introducing a new requirement like this and
immediately making it a SHALL seemed a bit extreme. I do think this, or
a requirement like this, ought to be a stronger requirement in the future.
Note that SP 800-63 is not currently under revision - the document suite
was published last summer following two public comment periods, one of
which was quote lengthy. I do not expect this wording to change until
the next revision, at the earliest.
-Jim
(still my personal opinions)
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.
