<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 11/17/20 1:09 PM, Phillip
      Hallam-Baker wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMm+LwhpZb3zC12pdieNB1siBLyx39uKvt0dSpskUmfv8_5kXg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Some of the password stupidity we suffer from today
        comes from the two weeks after the release of Crack. At the
        time, UNIX password files were world readable by default and
        anyone suggesting shadow password files was the way to go was
        attacked for 'security through security'. Crack upped the ante
        because it could make 6? 60? attempts a second and so a moderate
        sized cluster of SPARCstations could test every password in a
        million entry dictionary in a weekend. <br>
      </div>
    </blockquote>
    <p>But readable password hashes have gone away. Passwords are only
      readable on systems that are already quite broken. (Any old Unix
      systems still running are quite broken.) To set password policy
      based this case is all wrong.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAMm+LwhpZb3zC12pdieNB1siBLyx39uKvt0dSpskUmfv8_5kXg@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default" style="font-size:small">Battery Horse
          Staple Correct is 2^60 bits of work factor. That is not strong
          enough.</div>
      </div>
    </blockquote>
    <p>If the target system has already been broken into, correct. But
      if one has to brute force through a login program? 2^60 is more
      than plenty!</p>
    <p>If I have done my math correctly, to be certain of breaking in in
      100-years, one would have to get the login to test passwords for
      you at over a 6 MHz rate that entire time. Appropriately faster to
      get in appropriately sooner.<br>
    </p>
    <p>Only the crappiest systems will have no login throttling and if
      they are that crappy they will respond far slower than that
      because they areā€¦.crappy.<br>
    </p>
    <p><br>
    </p>
    <p>This gets me to an oft ignored point: passwords (something that
      has to be tested against some authority) are completely different
      from encryption passphrases (which, given ciphertext, can be
      tested in parallel and at arbitrary speeds).</p>
    <p><br>
    </p>
    <p>Rules for passwords need to be completely different from those
      for encryption passphrases. In that case, you are correct: "there
      is simply no ENCRYPTION PASSPHRASE that is long enough to be
      secure that is short enough to be memorable".</p>
    <p><br>
    </p>
    <p>-kb</p>
    <br>
  </body>
</html>