[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1HnjKO72=B9zAnQPVVauNwQvp+5zOfeoH8yyq4JFzHfTQ@mail.gmail.com>
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 [0]. 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
[0] 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. 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.
