Yeah, I'm kind of surprised that the age of HTTPS-All-The-Things hasn't led to a resurgence in the use of Basic Auth. As you note, the security problems that have been the big knock on Basic Auth for decades are completely obviated if your whole site is served over HTTPS.

My guess on the reason why is two-fold. First, we've been telling people that Basic Auth is a terrible thing only stupid people would use for more than two decades now, and once a lesson like that gets hammered deep enough into the mass consciousness it tends to stay there even long after the underlying facts have changed. And second, using Basic Auth means giving up any possibility of styling/designing your login experience and relying instead on the browser's built-in dialogs, which tend to be clunky and ugly in the extreme.

The UX for basic auth is terrible on most browsers. In Firefox, the dialog box refuses to give up focus, preventing me from copying the password from my password manager (which, while integrated into the browser, doesn't support filling basic auth dialogs).

I've had reasonably good experiences with filling out Basic Auth dialogs in Firefox via KeePassXC/KeePassXC-Browser. But by "reasonably good" I mean that it works, the password gets filled in, but the whole experience is still more clunky and error-prone than filling in an HTML login form would be. So yeah, lots of room for improvement here.

It's still a security risk. MITM happens regularly. Which means you better constrain it to either low-risk auth, or to networks you completely control.

For further risks, see e.g. https://security.stackexchange.com/questions/988/is-basic-au...

Yes, it's simple. And you're trading off security for simplicity. Make that choice, maybe, for your Intranet or your small blog. Commercial sites that have stored PII really, REALLY shouldn't.

> It's still a security risk. MITM happens regularly.

Then it's more or less as broken as alternative authentication methods

Nope. Because other methods never transmit a password in cleartext. (And they especially don't transmit it with every single request)

How do they manage this feat over unencrypted stateless http? Surely they must transmit something with every request?

Thanks for the link, it's a good summary of the trade offs.

I think any thorough investigation will conclude that there is, in fact, no way to securely authenticate a web user over unencrypted http.