This has many flaws that make it impractical beyond hobby projects or projects with a small set of users:
- It's trickier to throttle credential checks as every request is a login request, effectively
- It's hard to easily build account recovery flows or captchas into the login process.
- The UX of logging in/out is browser-dependent and confusing for users
- it can't integrate well with other auth systems
- Sending a password on every request requires care to avoid accidentally logging passwords
- Every request needs to do password validation, presenting additional load on the authentication systems/datastores
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.
Just because something is simple doesn't make it impractical. Not every application requires a complex auth-flow.
>As every request is a login request, effectively
This is the case with basically every single Authentication flow in existence...at the end of the day, no matter how and where credentials are verified, there is a token that has to be sent with every request and verified server side.
>hard to easily build account recovery flows
Why?
> UX of logging in/out is browser-dependent and confusing for users
Its a display with username/password and one or 2 buttons, one of which says "Login", the other of which says "Cancel" or something similar. How is this confusing?
Completely agree. My points generally apply a lot more to large scale systems.
> every request is a login request
While it's true that every request has something being verified for authentication purposes, login is a higher risk activity: username/password can get harvested in lots of ways, while session cookies etc. generally are harder to steal, meaning there is less risk of an attacker being present with auth cookies vs seeing a username / password
> account recovery
The way I've seen browsers implement password auth generally blocks interacting with the rest of the page. While a normal login form might have a "forgot password / email" link, with basic auth the user is stuck with a modal that the web site owner has no control over and cannot build such affordances.
> integration with other auth systems
In general, other auth systems take a set of credentials and then issue a token that can be used for further authentication. Basic Auth's design is that the same credential is used for every request. I guess you could build a hybrid auth system that can accept either cookies/headers from an alternative system, or basic auth and just have some sort of rules for dealing with what happens if both are present, but at that point why not just use a normal login page if you're already dealing with support for session tokens of some sort?
> username/password can get harvested in lots of ways,
BasicAuth isn't more at risk of this than other methods however. Unless a website doesn't use HTTPS, but if that's the case, all talk about security is out the window anyway.
> The way I've seen browsers implement password auth generally blocks interacting with the rest of the page.
BasicAuth Challenge -> Wrong Password -> Server replies with 200 + "Did you forget your password klick here ..." page instead of 401. There, pwd recovery system implemented using BasicAuth.
My comment about username/password being harvested was talking about how someone's password can get stolen: you can have malware, password reuse across sites, phishing, or other social engineering. For session cookies, you have basically malware as the compromise vector. Hence, passwords should be treated with more suspicion by an authentication system.
They don't, though. Users don't reuse session cookies between sites, so another site compromised doesn't mean you have to worry about existing sessions being compromised on your site. Users also don't know their session cookies so are far less likely to go typing them in to a phishing site or hand them out over the phone. A password is vulnerable to all of these scenarios.
Probably true. I’m not suggesting it for your enterprise project. I’m just trying to remove personal roadblocks so I can test an MVP before I invest too much development time.
Yes, I did. Hence why I pointed out one of the characteristics that made it work fine in the scenario mentioned (that it has a relatively small set of users that can be trained), and many of the concerns I mentioned are not particularly applicable to the situation which the OP presented. I was making the point that the OP's success is not necessarily transferable to large scale applications.
