

What happened to HTTP authentication? - ks
http://www.rooftopsolutions.nl/blog/what-happened-to-http-authentication

======
tptacek
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
_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
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
>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#Ad...](http://en.wikipedia.org/wiki/Digest_access_authentication#Advantages)

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

~~~
tptacek
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.

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

------
k-zed
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.

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

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

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

~~~
ks
Dzone also has a copy

<http://css.dzone.com/news/what-happened-http>

------
abalashov
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
It lives on in regular old HTTP proxy authentication, as used by a corporate
network near you.

------
smackfu
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
In Firefox, Tools -> Clear Recent History -> Active Logins

Yes, it's terrible

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

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

~~~
pwim
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
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

