* Application designers want to control the login/logout experience for users; HTTP auth delegates it to the browser's UI. Here's a telling example: where do you put the "Forgot password?" option on a site that uses HTTP auth?
* There's no logout and no inherent state tracking and to add either of these in-app you have to use the same hacky-seeming techniques you need for form-based auth.
* The "advanced" stuff you can do with HTTP auth (digest auth, for instance) isn't a real security win, especially vs. form-auth and TLS.
* The advanced stuff that is a win, like multi-factor, requires you to keep step-by-step control over the login experience and so isn't amenable to being delegated to the browser.
* It's just not better than web forms as a user experience. Popups are intrusive and ugly.
At the end of the day, there are a couple minor changes all browsers could make in concert merely to make HTTP Auth experience as good as the form auth experience; this would cost many tens of millions of dollars to deploy and would result in an Internet unlikely to be one iota better than what we have now.
Application designers want to control the login/logout experience for users
This could have been achieved by allowing a custom form in the 501 response page.
Where do you put the "Forgot password?" option on a site that uses HTTP auth?
Also in the 501 response.
404 pages have been tailored to great extremes. Why not the 501s?
The "advanced" stuff you can do with HTTP auth [...] isn't a real security win, especially vs. form-auth and TLS.
Digest auth has the distinct advantage that the password is never sent to the server at all. With forms over TLS the password can be intercepted on the server doing the validation. With digest auth this is not possible.
There are a couple minor changes all browsers could make [...]; this would cost many tens of millions of dollars
The real question is, why didn't browsers evolve in that direction to begin with, before too much was invested in form-based authentication?
Ok, your proposal is, "application designers will control the login experience by invoking a browser-controlled popup box over which they have virtually no control, and then, when that popup fails, they can do a really creative error page". I think you're making my point for me.
Your point about the security of digest auth appears to be the actual inverse of reality. Allowing for the fact that I could be wrong, since I think about HTTP Authentication very rarely in my professional career, since nobody uses it and nobody ever will, can you account for the fact that in order to verify digests, the server actually needs to store the plaintext of the password, and not a hash? This is exactly the problem SRP was designed to solve.
Browsers didn't evolve in this direction because HTTP Auth was never a win over form auth. Form login is prettier than HTTP authentication, it's more usable, it's less intrusive, it's more flexible, it's easier to implement, 90% of it is required anyways since every app in the universe still needs a secure session store, and its future-proof.
No, that's not his proposal. The 401 message (which is what he meant to say) is what prompts the browser to display the popup box in the first place. The idea would be that if you provide a custom form there, the browser displays your custom form (in the browser window) in place of the default popup.
Then all you need to add is a couple of Javascript methods to allow that custom form to set the HTTP Auth parameters and retry (you could even use a special form target for that, if you wanted to, avoiding Javascript entirely).
On the other hand, wikipedia also points out my other gut reaction to the article, which is that forms over https basically provide all the same advantages without most of the drawbacks.
At first that appears to not store the plaintext of the password, but looking closer, isn't it really using the hash as a password? That is, if the bad guys got a copy of the hashes stored on the server, they could use a modified client to log in.
The protocol is requiring the client to prove that the client knows that hash, not that the client knows the password, if I'm reading it right (I might not be).
Yes, the intermediate hash is password-equivalent, but at least you haven't (directly) handed over your Google Mail password at the same time.
SRP was designed, in part, to make the serverside storage of passwords crypto-hard to break. It's an elegant protocol, but it's a little more complex than digest auth.
None of this stuff is anywhere nearly as safe as bcrypt and TLS with form auth. Digest HTTP auth can, in fact, make you even less safe than unencrypted form auth.
You're right; if you go out of your way, you can instead store an extraordinarily viciously crackable derivative of the password. I'd stick with basic auth and use BCrypt on the server; you're far more likely to lose your whole password database than you are to lose a significant number of basic auth logins to interception.
501 is "not implemented", I don't see how that's relevant? The server sends a "401 Unauthorized", which is what prompts the browser to show the password prompt. The thing is, I've seldom seen such a page -- because the browser shows me a login prompt.
On face value, I tend to agree with the OP that it would be cleaner if we could use HTTP auth for real things. In practise, there's simply so much missing from the equation, combined with a very mature selection of software that makes this very easy to do in any webapp, to be something worth wasting efforts on.
Is it really even cleaner? I understand why people say that --- because web services clients usually don't have a notion of "cookies" --- but at pretty much the same level of security and convenience as HTTP Authentication, you can also issue persistent access tokens. I don't see how a token is in any way inferior to embedding authentication in an HTTP header.
It's cleaner because you, in theory, can outsource an entire functionality class to your infrastructure. Less complexity for you to deal with.
A bit like serving static files - you put your files in a directory, and they're not only served, they're served faster, better and more reliably and scalable than whatever you can code as part of your app.
I don't understand the end to end argument then? I'd say it's a huge win for cleanliness that I never need to touch a buffer in my life, but can still build and deploy high performance web apps, because I can build on the Apaches/nginx/whatevers of the world.
Requiring users to log in in modern web stacks is indeed just a question of setting a flag, and it's done for you, you never need to know about, let alone consider encryption of, session cookies, so this is outsourced down the stack (and sufficiently clean for anything I can think of). Just not as far down as the HTTP standard suggests is possible.
You make valid points, but I think that some of them could be addressed to improve the current situation.
1. Allow the server to dictate to the browser some customizations of the dialog box. For instance, the server could instruct the browser where "Forgot Password" or "Forgot Username" links should point. In their absence, the browser does not present those links. The same could be done for "logout" links that can appear somewhere in the browser toolbar if you're logged in (see #2).
2. Just like session information, basic authentication information must be sent from the browser to the server every time a resource is requested. State is trivial to manage: if the server returns 401, the user is not logged in. If the server returns a 200-series response, then the browser knows that the username/password work and can display a modified url, as someone suggested, ala "http://rgejman@news.ycombinator.com/resource. The browser continues to show this as long as the last page visited gave a 200-series response.
Changing who is logged in thus becomes trivial: click on the username in the url and you get the option to login as another user. This prompts the browser to refresh the current page with the new basic auth info, etc.
You can still track state using sessions, but now you have nice separation of functions. Basic auth is used for managing authentication and sessions are used for tracking state. Much more elegant this way IMO.
3. Digest auth is a nice security win only insofar as you don't have to transfer passwords, but I agree that SSL is really the way to go. Why can't you do SSL + basic auth?
4. Multi-factor auth is a good point, but not insolvable. It needs some hard thinking to do well, but it could be done in an elegant way. I can elaborate if you're interested.
5. I think web forms have a lot of problems, most notably the lack of standardization. My parents often have trouble locating the login/registration/logout pages on websites—and I have seen many others with the same problem. Allowing this to be handled by the browser would lower the learning curve for many people and allow them to use a variety of websites without difficulty.
This is a thoughtful comment, and I modded it up, but I can't resist saying this: your proposals basically suggest that we accept a lowest-common-denominator CRUD-app style login model and then bake it into the browser. We'd do that, freezing out any innovation or flexibility in login design, in order to... catch up to where we already are with forms.
There are definitely crappy login forms. So what? If an app can't clear the usability hurdle of getting people logged in, it's certainly not going to clear the (even harder) hurdles of "doing something useful for the user". In the end, many hundreds of millions of logins happen by all sorts of users every day. Lack of login-page standards doesn't seem like a real problem.
Your first point is excellent. But I'll raise you one. What if a login/logout cycle were made generic and could include several steps. The server says "401. You've got to login. I need a %username% and %password% and then I'm going to ask you one more thing." The browser asks the user for the username/password and then hits up the server with the response. If the authentication of u/p is successful it says "display this HTML doc and send me the result for final validation."
That sort of a model could work for both standard username/password setups and multiple-factor authentication. It's standard, flexible, predictable and you never have to search for it on an unfamiliar website.
As for your second point: there are plenty of websites that are difficult to login to even though they are used by millions. Try Citibank for one particularly bad example.
> Allowing this to be handled by the browser would lower the learning curve for many people and allow them to use a variety of websites without difficulty.
I agree that it would make it easier to use, but so would allowing the browser to handle site search, and comment posting, and link presentation... Where do you draw the line?
The point I was trying to make with my post (under the "What's missing?" header) is that if some of these hurdles are removed (custom login forms, based on html, etc) it would greatly improve the programmability of the web.
I think the horse is out of the barn on this one - HTTP auth isn't going to come back. Even if all the browser vendors went and fixed the issues listed in this article tomorrow, HTTP auth still wouldn't support federated identity scenarios which is being used more and more every day.
The reason why we should use HTTP authentication is similar to why we can have custom stylesheets, or why everyone should just use nntp instead of web forums, or a MUA instead of web mail.
"Content" shouldn't provide its own "style" - the user should be free to choose whatever matter of presentation they desire.
Furthermore, using HTTP authentication everywhere (at least as an omnipresent alternative) would make sites much more programmable, and thus accessible.
It lives on very promisingly--and largely unadulterated--in the world of SIP digest authentication for a) registration requests (401 Unauthorized) and b) proxy challenges for outbound calls (407 Proxy Authentication Required).
It sends Base64 encoded passwords. So if you use http it is basically cleartext. You still don't need to store the passwords in cleartext, as you can use the same hashing mechanisms you would with other login methods.
I thought for digest auth, it the server sends a new nonce, and then asks for md5(md5(username:password):nonce:md5(something i forget)) - you couldn't verify that unless you had access to the raw password, no?
* Application designers want to control the login/logout experience for users; HTTP auth delegates it to the browser's UI. Here's a telling example: where do you put the "Forgot password?" option on a site that uses HTTP auth?
* There's no logout and no inherent state tracking and to add either of these in-app you have to use the same hacky-seeming techniques you need for form-based auth.
* The "advanced" stuff you can do with HTTP auth (digest auth, for instance) isn't a real security win, especially vs. form-auth and TLS.
* The advanced stuff that is a win, like multi-factor, requires you to keep step-by-step control over the login experience and so isn't amenable to being delegated to the browser.
* It's just not better than web forms as a user experience. Popups are intrusive and ugly.
At the end of the day, there are a couple minor changes all browsers could make in concert merely to make HTTP Auth experience as good as the form auth experience; this would cost many tens of millions of dollars to deploy and would result in an Internet unlikely to be one iota better than what we have now.