5 ms·

What happened to HTTP authentication?

76 points by ks 16y ago

troygoode 16y ago
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.
tptacek 16y ago
It simply isn't a win. * 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.
- mansr 16y ago
  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?
  - tptacek 16y ago
    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.
    - falien 16y ago
      >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? That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages 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.
      - tzs 16y ago
        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).
        16y ago
- rgejman 16y ago
  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. 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.
  - tptacek 16y ago
    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.
- evrt 16y ago
  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.
borisk 16y ago
"HTTP Authentication may be RESTful, but it's not very USEful." http://www.artima.com/weblogs/viewpost.jsp?thread=155252 http://www.artima.com/weblogs/viewpost.jsp?thread=155252
fname 16y ago
Sites dead... Google's got it: http://webcache.googleusercontent.com/search?q=cache:http://www.rooftopsolutions.nl/blog/what-happened-to-http-authentication&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
- ks 16y ago
  Dzone also has a copy http://css.dzone.com/news/what-happened-http http://css.dzone.com/news/what-happened-http
abalashov 16y ago
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).
- caf 16y ago
  It lives on in regular old HTTP proxy authentication, as used by a corporate network near you.
albertzeyer 16y ago
People don't like popups. Esp. none with just bare text.
joshu 16y ago
IIRC, the digest HTTP auth stuff essentially forces you to store cleartext passwords.
- pwim 16y ago
  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.
  - joshu 16y ago
    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? summon @tpateck
k-zed 16y ago
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.
smackfu 16y ago
Isn't the big issue that none of the browsers ever implemented logout of any kind, and just expected you to close your browser?
- vsync 16y ago
  In Firefox, Tools -> Clear Recent History -> Active Logins Yes, it's terrible
vsync 16y ago
Basic auth is insecure except over SSL. Digest auth is secure, but Internet Explorer ruined it for everyone.

76 points by ks 16y ago

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.

tptacek 16y ago

It simply isn't a win. * 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.

mansr 16y ago
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?
- tptacek 16y ago
  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.
  - falien 16y ago
    >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? That was my first thought too, but apparently doesn't have to be the case. http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages 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.
    - tzs 16y ago
      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).
      - 16y ago
rgejman 16y ago
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. 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.
- tptacek 16y ago
  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.
evrt 16y ago
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.

borisk 16y ago

"HTTP Authentication may be RESTful, but it's not very USEful." http://www.artima.com/weblogs/viewpost.jsp?thread=155252 http://www.artima.com/weblogs/viewpost.jsp?thread=155252

fname 16y ago

Sites dead... Google's got it: http://webcache.googleusercontent.com/search?q=cache:http://www.rooftopsolutions.nl/blog/what-happened-to-http-authentication&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...

ks 16y ago
Dzone also has a copy http://css.dzone.com/news/what-happened-http http://css.dzone.com/news/what-happened-http

abalashov 16y ago

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).

caf 16y ago
It lives on in regular old HTTP proxy authentication, as used by a corporate network near you.

albertzeyer 16y ago

People don't like popups. Esp. none with just bare text.

joshu 16y ago

IIRC, the digest HTTP auth stuff essentially forces you to store cleartext passwords.

pwim 16y ago
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.
- joshu 16y ago
  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? summon @tpateck

k-zed 16y ago

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.

smackfu 16y ago

Isn't the big issue that none of the browsers ever implemented logout of any kind, and just expected you to close your browser?

vsync 16y ago
In Firefox, Tools -> Clear Recent History -> Active Logins Yes, it's terrible

vsync 16y ago

Basic auth is insecure except over SSL. Digest auth is secure, but Internet Explorer ruined it for everyone.