4 ms·

I wish web sites just used HTTP authentication over HTTPS. I'd love to get all the hours back that I've spent writing scripts to automate operations against web

I wish web sites just used HTTP authentication over HTTPS. I'd love to get all the hours back that I've spent writing scripts to automate operations against web sites with home-grown forms-based authentication.

tptacek 13y ago
There's a reason HTTP Authentication isn't widely used. It's significantly harder to style, which means it's hard to work password reset into it. It doesn't easily admit to "logout", which is an important security mechanism. In 2013 applications use sessions for far more than just authentication. It doesn't gracefully handle token authentication. It doesn't make play well with single sign-on. It doesn't even make sense in a world where your phone or fingerprint authenticates you to an app. The right way to think of HTTP Authentication is as an experiment that failed.
- wtbob 13y ago
  > It's significantly harder to style, which means it's hard to work password reset into it. Couldn't that have been fixed with a new parameter in the Authentication header? > It doesn't easily admit to "logout" I think it easily admits logout—the browser should have a piece of UI which reads 'logout'... > It doesn't gracefully handle token authentication. It could be extended to do that, with a new authentication type, right?
lobster_johnson 13y ago
There are several problems with using HTTP auth as a replacement for login forms. The biggest problem, perhaps, is that it's mutually exclusive: A resource is either protected by auth, or it isn't. There is no room in the spec for pages that change their meaning depending on whether you are logged in or not. Of course, one could argue that "logged in" pages should have different URLs, eg., /logged_in/*, and just use auth for those. The problem with that approach is that if you go to any resource not within that URL namespace, such as the front page, auth isn't necessarily sent by the browser, and so you can't know if the user is logged into the other parts of the site. Nor is there anything that supports the notion of "login sessions" -- once you're authenticated, you can't un-authenticate, as far as I know. We actually have a payment provider (DIBS, a Scandinavian company) that uses basic auth for their admin login. The only way to log out of their admin, such as in order to log into a different account, is to clear the browser state. And lastly, the login popup that browsers currently provide for basic auth is poorly implemented and altogether too simple. There is no way to ask for password recovery, for example, and there is no way to provide a signup button.
danielweber 13y ago
The one good thing about HTTP Auth, IIRC from the last time it looked, was that it was sorta CSRF-resistant to a form automatically logging you in (if it could guess your password -- which for something like a home router, is a decent attack vector in a spray-and-pray script where there are lots of defaults). But it still has so many significant downsides, like the fact that you were kept logged in until you closed your browser.

tptacek 13y ago

There's a reason HTTP Authentication isn't widely used. It's significantly harder to style, which means it's hard to work password reset into it. It doesn't easily admit to "logout", which is an important security mechanism. In 2013 applications use sessions for far more than just authentication. It doesn't gracefully handle token authentication. It doesn't make play well with single sign-on. It doesn't even make sense in a world where your phone or fingerprint authenticates you to an app. The right way to think of HTTP Authentication is as an experiment that failed.

wtbob 13y ago
> It's significantly harder to style, which means it's hard to work password reset into it. Couldn't that have been fixed with a new parameter in the Authentication header? > It doesn't easily admit to "logout" I think it easily admits logout—the browser should have a piece of UI which reads 'logout'... > It doesn't gracefully handle token authentication. It could be extended to do that, with a new authentication type, right?

lobster_johnson 13y ago

There are several problems with using HTTP auth as a replacement for login forms. The biggest problem, perhaps, is that it's mutually exclusive: A resource is either protected by auth, or it isn't. There is no room in the spec for pages that change their meaning depending on whether you are logged in or not. Of course, one could argue that "logged in" pages should have different URLs, eg., /logged_in/*, and just use auth for those. The problem with that approach is that if you go to any resource not within that URL namespace, such as the front page, auth isn't necessarily sent by the browser, and so you can't know if the user is logged into the other parts of the site. Nor is there anything that supports the notion of "login sessions" -- once you're authenticated, you can't un-authenticate, as far as I know. We actually have a payment provider (DIBS, a Scandinavian company) that uses basic auth for their admin login. The only way to log out of their admin, such as in order to log into a different account, is to clear the browser state. And lastly, the login popup that browsers currently provide for basic auth is poorly implemented and altogether too simple. There is no way to ask for password recovery, for example, and there is no way to provide a signup button.

danielweber 13y ago

The one good thing about HTTP Auth, IIRC from the last time it looked, was that it was sorta CSRF-resistant to a form automatically logging you in (if it could guess your password -- which for something like a home router, is a decent attack vector in a spray-and-pray script where there are lots of defaults). But it still has so many significant downsides, like the fact that you were kept logged in until you closed your browser.