>The password is still revealed to the server.

And with digest auth, the server must have the plain text password already. But sure, maybe there is a third option.

> There are password verification protocols where the password is not revealed to the server either, which is much more secure as it means that you’re not at the mercy of whether the sever operator follows good security practices about not saving your password in plain text somewhere.

Well, the most common such protocol is TOTP, which still requires the server to store your full password. In that sense it's worse than a naive password exchange, which only requires the server to store your hashed password.

There are other password protocols that require neither transmission nor server retention of the full password, but it seems worth noting that the protocol we actually have didn't bother with that.

Does it matter if the pw is stored salted and hashed?

Yes, that's why we do that.

I'm not sure what you want to ask.

As every other login form does. In this situation basic authentication is no different from every other authentication mechanism that uses passwords...

Not necessarily, you can set up TLS client auth with signed certificates, generated locally, that the server never receives the private key of. The server can validate and authenticate without knowledge of the secret, and cannot impersonate the user.

The problem with TLS client certs, of course, is the fact you need a method of signing CSR's, and the terrible UX modern browsers have for client auth, especially on mobile.

Yes in theory you can but it's a pain, a certificate needs to be installed in the browser, the user gets a popup every time saying that you want to use a certificate, when the user changes computer either needs to backup the certificate or install it again, etc. My bank did that in the past and they no longer support that, instead they opted for a classical multiple factor authentication: password + authorize the access with your phone.