Date: Thu, 15 Mar 2018 13:28:01 -0400 From: Matt Weir <cweir@...edu> To: passwords@...ts.openwall.com Subject: Re: Submitting Partial Password Hashes to Pwned Password Lookup Arnold, Thanks for the comments! I've looked into that topic in the past and the current state of HSMs resembled the wild wild west. That being said, more and more cloud providers are providing access to HSMs for deployments . If I had to point to two blockers for widespread adoption I'd say cost (why should security money be spent here vs ensuring they don't get hacked in the first place), and lack of standard libraries/interfaces. Aka there is a *ton* of custom development to make sure your applications play nice with the HSM and then there's the cost of the HSM itself. >> The cost of such measures, at least for large installations, is not great compared to the risks avoided. I've gotten, (and agree with), a lot of push-back on similar statements to the above. The cost can be deceptively high when it comes to custom code, maintenance, and administration. For example, things like altering your backup/restore procedures can sneak up on you in unexpected ways. Also these HSMs become mission critical pieces where a failure can render your entire service unavailable, (which can cost lots of money). At the same time "risks avoided" can quickly become an contentious conversation. So I'm not disagreeing with you that I'd love to see password cracking become a thing of the past! I'm just jaded on the feasibility of widespread deployment of HSMs. Cheers, Matt  https://aws.amazon.com/cloudhsm/ On Thu, Mar 15, 2018 at 12:24 PM, Arnold Reinhold <agr@...com> wrote: > 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. 220.127.116.11): “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.