<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/27/20 8:35 AM, William Herrin
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP-guGU=O6DFeTHUhcRUqkeqOuGC=w3x5Vx70-rHo+LNr6qXDQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">On Mon, Apr 27, 2020 at 7:14 AM Michael Thomas <a class="moz-txt-link-rfc2396E" href="mailto:mike@mtcc.com"><mike@mtcc.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On 4/26/20 8:39 PM, Matt Palmer wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">Which exactly zero deployment. And you need to store the plain-text password
on the server side. What could possibly go wrong?
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">But you said that *passwords on the wire* were the biggest problem.  Digest
auth solves that.  Also, you don't have to store the plain-text password.
</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Correct. You need only store the realm/user/password digest. The chief
problem with digest authentication is that the web site has no control
over the UI. Among the many issues, this makes it tricky to reliably
capture a digest in the first place without the server at least
briefly knowing the password. I don't know if webauthn corrects this
or makes similar blunders.</pre>
    </blockquote>
    <p>Webauthn corrects this by not using passwords at all. It uses
      public key crypto which has the nice property that the thing that
      the server remembers is, um, public. A compromise of public keys
      -- unlike unsalted password hashes in the LinkedIn case -- does no
      harm. That was the insight that Paul, Steven and I had with RFC
      7486 back in 2012, as we mashed together two different ways going
      about that in our experimental rfc. 
    </p>
    <p>I'll stand by my initial stance: passwords over the wire remain
      the largest security hole on the net because their reuse means you
      only have to target the weakest sites to harvest them. Worse, you
      can create an active attack to get people to just give you their
      passwords by setting up some interesting site that requires an
      account whose actual purpose is to harvest passwords. Digest does
      exactly nothing to deal with that problem.<br>
    </p>
    <p>Also, says wikipedia about digest:<br>
    </p>
    <h3 style="color: rgb(0, 0, 0); background: none rgb(255, 255, 255);
      font-weight: bold; margin: 0.3em 0px 0px; overflow: hidden;
      padding-top: 0.5em; padding-bottom: 0px; border-bottom: 0px;
      font-size: 1.2em; line-height: 1.6; font-family: sans-serif;
      font-style: normal; font-variant-ligatures: normal;
      font-variant-caps: normal; letter-spacing: normal; orphans: 2;
      text-align: start; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px;
      -webkit-text-stroke-width: 0px; text-decoration-style: initial;
      text-decoration-color: initial;"><span class="mw-headline"
        id="Disadvantages">Disadvantages</span><span
        class="mw-editsection" style="font-family: sans-serif;
        user-select: none; font-size: small; font-weight: normal;
        margin-left: 1em; vertical-align: baseline; line-height: 1em;
        white-space: nowrap; unicode-bidi: isolate;"><span
          class="mw-editsection-bracket" style="margin-right: 0.25em;
          color: rgb(84, 89, 93);">[</span><a
href="https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&action=edit&section=5"
          title="Edit section: Disadvantages" style="text-decoration:
          none; color: rgb(11, 0, 128); background: none;">edit</a><span
          class="mw-editsection-bracket" style="margin-left: 0.25em;
          color: rgb(84, 89, 93);">]</span></span></h3>
    <p style="margin: 0.5em 0px; color: rgb(34, 34, 34); font-family:
      sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: 400; letter-spacing: normal; orphans: 2; text-align:
      start; text-indent: 0px; text-transform: none; white-space:
      normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width:
      0px; background-color: rgb(255, 255, 255); text-decoration-style:
      initial; text-decoration-color: initial;">There are several
      drawbacks with digest access authentication:</p>
    <ul style="list-style-image:
url("/w/skins/Vector/resources/skins.vector.styles/images/bullet-icon.svg?872f1");
      margin: 0.3em 0px 0px 1.6em; padding: 0px; color: rgb(34, 34, 34);
      font-family: sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: 400; letter-spacing: normal; orphans: 2; text-align:
      start; text-indent: 0px; text-transform: none; white-space:
      normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width:
      0px; background-color: rgb(255, 255, 255); text-decoration-style:
      initial; text-decoration-color: initial;">
      <li style="margin-bottom: 0.1em;">The website has no control over
        the user interface presented to the end user.</li>
      <li style="margin-bottom: 0.1em;">Many of the security options in<span> </span><a
          class="external mw-magiclink-rfc" rel="nofollow"
          href="https://tools.ietf.org/html/rfc2617"
          style="text-decoration: none; color: rgb(102, 51, 102);
          background: linear-gradient(transparent, transparent) right
          center no-repeat,
url("/w/skins/Vector/resources/skins.vector.styles/images/external-link-ltr-icon.svg?b4b84");
          padding-right: 13px;">RFC 2617</a><span> </span>are optional.
        If quality-of-protection (qop) is not specified by the server,
        the client will operate in a security-reduced legacy<span> </span><a
          class="external mw-magiclink-rfc" rel="nofollow"
          href="https://tools.ietf.org/html/rfc2069"
          style="text-decoration: none; color: rgb(102, 51, 102);
          background: linear-gradient(transparent, transparent) right
          center no-repeat,
url("/w/skins/Vector/resources/skins.vector.styles/images/external-link-ltr-icon.svg?b4b84");
          padding-right: 13px;">RFC 2069</a><span> </span>mode</li>
      <li style="margin-bottom: 0.1em;">Digest access authentication is
        vulnerable to a<span> </span><a
          href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack"
          title="Man-in-the-middle attack" style="text-decoration: none;
          color: rgb(11, 0, 128); background: none;">man-in-the-middle
          (MITM) attack</a>. For example, a MITM attacker could tell
        clients to use basic access authentication or legacy RFC2069
        digest access authentication mode. To extend this further,
        digest access authentication provides no mechanism for clients
        to verify the server's identity</li>
      <li style="margin-bottom: 0.1em;">Some servers require passwords
        to be stored using reversible encryption. However, it is
        possible to instead store the digested value of the username,
        realm, and password<sup id="cite_ref-5" class="reference"
          style="line-height: 1; unicode-bidi: isolate; white-space:
          nowrap; font-weight: normal; font-style: normal; font-size:
          11.2px;"><a
href="https://en.wikipedia.org/wiki/Digest_access_authentication#cite_note-5"
            style="text-decoration: none; color: rgb(11, 0, 128);
            background: none;">[5]</a></sup></li>
      <li style="margin-bottom: 0.1em;">It prevents the use of a strong
        password hash (such as<span> </span><a
          href="https://en.wikipedia.org/wiki/Bcrypt" title="Bcrypt"
          style="text-decoration: none; color: rgb(11, 0, 128);
          background: none;">bcrypt</a>) when storing passwords (since
        either the password, or the digested username, realm and
        password must be recoverable)</li>
    </ul>
    <p style="margin: 0.5em 0px; color: rgb(34, 34, 34); font-family:
      sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: 400; letter-spacing: normal; orphans: 2; text-align:
      start; text-indent: 0px; text-transform: none; white-space:
      normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width:
      0px; background-color: rgb(255, 255, 255); text-decoration-style:
      initial; text-decoration-color: initial;"><br>
    </p>
    <p style="margin: 0.5em 0px; color: rgb(34, 34, 34); font-family:
      sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: 400; letter-spacing: normal; orphans: 2; text-align:
      start; text-indent: 0px; text-transform: none; white-space:
      normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width:
      0px; background-color: rgb(255, 255, 255); text-decoration-style:
      initial; text-decoration-color: initial;">So my memory doesn't
      seem to be completely wrong here. It's been ages since I've
      thought about digest. <br>
    </p>
    <p style="margin: 0.5em 0px; color: rgb(34, 34, 34); font-family:
      sans-serif; font-size: 14px; font-style: normal;
      font-variant-ligatures: normal; font-variant-caps: normal;
      font-weight: 400; letter-spacing: normal; orphans: 2; text-align:
      start; text-indent: 0px; text-transform: none; white-space:
      normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width:
      0px; background-color: rgb(255, 255, 255); text-decoration-style:
      initial; text-decoration-color: initial;"><br>
    </p>
    <blockquote type="cite"
cite="mid:CAP-guGU=O6DFeTHUhcRUqkeqOuGC=w3x5Vx70-rHo+LNr6qXDQ@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">

I can't speak to Steven, Paul, the w3c or any other non-posters to
this thread that you wish to employ in an appeal to authority fallacy
but with due respect, I think you hold a myopic view of network
security. For better or worse, security is a zero-sum game. The budget
stays proportional to the value of the asset being protected. When you
spend it on low-impact improvements you don't have it for the many
improvements with a higher impact than whether a web site knows the
password you chose for that web site.

</pre>
    </blockquote>
    <p>With webcrypto, you can do whatever you want these days, and use
      whatever UI you want. Webauthn is primarily about replacing
      user-facing passwords from what I can tell, but it seems like it
      was completely informed by crypto dongles and the business of
      selling them. While that might be fine for high value network
      equipment, etc, it adds a huge amount of complexity in what
      otherwise is a pretty straightforward use of public key
      cryptography: user enrolls their public key into the server auth
      backend (bound to some identity), you log in by the server sending
      you a nonce, etc which the browser signs with the corresponding
      public key which the server verifies. Done. Maybe I should do this
      again now that webcrypto is here instead of my janky javascript
      implementation. Trying to get webauthn to work with just local
      credentials was like pulling teeth and frighteningly complex for
      something that should be pretty straightforward. It would
      extremely disheartening if the best was the enemy of the good.<br>
    </p>
    <p>Mike<br>
    </p>
  </body>
</html>