[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <28F1284E-264E-46BC-8FE2-6723AA19103C@me.com>
Date: Thu, 15 Mar 2018 12:24:36 -0400
From: Arnold Reinhold <agr@...com>
To: passwords@...ts.openwall.com
Cc: Jim Fenton <fenton@...epopcorn.net>
Subject: Re: Submitting Partial Password Hashes to Pwned Password
Lookup
Telling people the password they have selected has been cracked in the past, when in all likelihood they will then select a password that is just as weak, doesn’t seem a very effective tactic. It is time to give up trying to fix the 1970s crypt(3) strategy of storing password validation data using an algorithm that lets anyone verify a guess.
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/
The rest of the IT world would then be put on notice. The cost of such measures, at least for large installations, is not great compared to the risks avoided. Transition from current methods can be seamless, just rehash existing hashes with the new security system. NIST could lay out the necessary steps is an advisory document to prevent implementation errors by security-clueless programmers.
As the quoted paragraph says, we have the technology to make password security effective with much simpler passwords. We should stop expecting users to do things we already know most never will, and instead put the burden on system operators to deploy safe methods for storing password data.
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.
