What happened to HTTP authentication?
rooftopsolutions.nl
rooftopsolutions.nl
* 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.
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?
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.
That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Ad...
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.
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).
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.
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 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.
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.
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.
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.
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.
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.
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?
"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.
Yes, it's terrible
summon @tpateck