I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec.
Some of your criticisms aren't exactly accurate though. "Sending a password on every request requires care to avoid accidentally logging passwords" applies to almost every login system ever made. Unless you use browser-based hashing with JavaScript, but that has significant known flaws and doesn't add much security.
And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse.
>I wonder if there would be an audience for an HTTP Basic Auth 2.0 spec.
Yes! I remember in the early aughts, IE6 would present this cool login screen [0] for (what I think, but may be remembering incorrectly) HTTP Basic Auth. I always wanted to do that, but didn't really understand anything other than making basic HTML pages.
It could help improve security. It's a ubiquitous login screen that makes it really obvious which domain is requesting credentials - no need to check if the page looks off to detect possible phishing. Oh and you wouldn't run in to the issue of accidentally logging in on the sign up page!
I wouldn't bet on it improving security, personally.
If I was a hacker, I can use the User-Agent to know what OS they are using (or close enough). I also know what browser they are using.
I can use this information to create a custom webpage with a white background and similar imagery to look like the native browser form. If the user was unsuspecting, they might not realize it's not a separate window, and think that they were logging into the correct site.
> And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse.
Not true. Once you get authenticated you can store that in a cookie with expiration, or any number of other ways to reduce load on auth services.
For 2, in many cases validating username/password requires hitting an external system. If you want to give your IT department a fun day, write a moderately popular internal web service that accidentally hits LDAP freshly for every single web request. It's really easy to accidentally do in some environments. Session cookie validation will typically only involve local resources.
For many of my internal tools I don't even bother with a database and just store it in local RAM, especially when I have no other database involvement, because having all sessions reset every few months during a reboot or restart is worth it to not have to stand up a database solely for that purpose. In that case it's just a quick lock&lookup in a map/dict/whatever your language favors to see if the token matches or not.
A non-trivial difference is that to validate password you need to run it through bcrypt or similar algorithm which is intentionally slow. With a token or cookie, you can use a regular fast hashing algorithm.
Some of your criticisms aren't exactly accurate though. "Sending a password on every request requires care to avoid accidentally logging passwords" applies to almost every login system ever made. Unless you use browser-based hashing with JavaScript, but that has significant known flaws and doesn't add much security.
And "Every request needs to do password validation, presenting additional load on the authentication systems/datastores" also applies to almost every login system ever made and HTTP Basic Auth doesn't make this better or worse.