Re: mail admins?

[Michael Thomas <mike () mtcc com>]

On 4/27/20 8:35 AM, William Herrin wrote:
> On Mon, Apr 27, 2020 at 7:14 AM Michael Thomas <mike () mtcc com> wrote:
> > On 4/26/20 8:39 PM, Matt Palmer wrote:
> > > On Sun, Apr 26, 2020 at 05:10:56PM -0700, Michael Thomas wrote:
> > > > Which exactly zero deployment. And you need to store the plain-text password
> > > > on the server side. What could possibly go wrong?
> > > 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.
> 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.

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.

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.

Also, says wikipedia about digest:


     Disadvantages[edit
     <https://en.wikipedia.org/w/index.php?title=Digest_access_authentication&action=edit&section=5>]

There are several drawbacks with digest access authentication:

 * The website has no control over the user interface presented to the
   end user.
 * Many of the security options inRFC 2617
   <https://tools.ietf.org/html/rfc2617>are optional. If
   quality-of-protection (qop) is not specified by the server, the
   client will operate in a security-reduced legacyRFC 2069
   <https://tools.ietf.org/html/rfc2069>mode
 * Digest access authentication is vulnerable to aman-in-the-middle
   (MITM) attack
   <https://en.wikipedia.org/wiki/Man-in-the-middle_attack>. 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
 * 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^[5]
   <https://en.wikipedia.org/wiki/Digest_access_authentication#cite_note-5>

 * It prevents the use of a strong password hash (such asbcrypt
   <https://en.wikipedia.org/wiki/Bcrypt>) when storing passwords
   (since either the password, or the digested username, realm and
   password must be recoverable)


So my memory doesn't seem to be completely wrong here. It's been ages 
since I've thought about digest.


> 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.
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.

Mike