Hacker News Reader

Comment by clark | Hacker News Reader

In my opinion, session cookies are primarily used as a work around since HTTP Authentication is incredibly ugly. Perhaps if that core problem was addressed, the need for cookies would be dramatically reduced.

View on HN

HTTP Authentication is dead and is never coming back. Leave aside all protocol design elegance arguments and think about the situation for app developers; form auth is simply better:

* It has a simple reliable log-out button.

* It gives app developers more reliable fine-grained control over the login process because it in no way relies on browser chrome.

* It better supports advanced security and UX idioms, like signup-or-register or SMS-me-a-one-time-login.

* Virtually every web app in the world needs a session-keyed store anyways, and authentication is the easiest of the AAA problems anyhow, so building that one tiny piece into the protocol doesn't solve any problems.

* [ps]

Doubtless there are a myriad of nitpicky arguments about how HTTP Auth can be massaged to mitigate these problems, but who cares? Cookie auth works for everyone. Basic auth manifestly does not. Why would anyone want to expend major effort to take an archaic protocol and make it asymptotically as good as what every web app stack already provides?

[ps]: Cookie auth schemes can also be extended without getting Microsoft, Mozilla, Google, and Apple to agree on anything; this is the [end-to-end argument in systems design] in action.

It's certainly not dead when it comes to RESTful web services APIs. It's often the best choice for authenticating these.

In a browser context, most of the UI criticisms have little to do with the protocol itself and could be easily addressed if browsers would add a little more HTML + javascript API support for doing HTTP auth logins and logouts. Admittedly that looks unlikely to happen in the near future, which is a shame IMO. IIRC they were considering it at one point for HTML5.

I feel like I could win an argument that it's never the best choice for authenticating RESTful services, because it implies that authentication is username/password based, and there are often better idioms for app-to-app / company-to-company authentication than usernames and passwords.

Gotcha.

Is there not any scope for improvement on this front using alternative HTTP auth schemes though? (As far as I'm aware the standard has room for schemes other than Basic and Digest, although I suppose limited to the challenge-response format)

At any rate, it'd be nice if there was an effort to work with the HTTP standard (or if not possible, propose extensions to it) and aim for clean protocol design where at all possible when driving to improve API security.

SSL + HTTP Auth has been pretty good for us, and it's a good fit for the RESTful design goals of the protocol, so I'd be sad to see it thrown out, rather than improved where necessary.

Seriously: the opposite of this sentiment is true. We should be working to hoist stuff out of HTTP. Authentication is a perfect example of something that endpoints should be able to decide without having their options influenced by the protocol.

If there's a single advantage to conveying a username/password in a dedicated HTTP header as opposed to any other way of using HTTP to convey the same information, it hasn't been well articulated to me. Down with HTTP Authentication!

I think you're right. If you look at the standard HTTP header fields, almost all of them demand/specify information about the resource itself, its representation, or the mechanics of the transfer thereof.

The others: Host - necessary for multiplexing over the predominant transport protocol Date - necessary for caching Referer - mostly useless and optional anyway User-Agent - information about the client and essentially useless Server - useless

And then there are the bastard children: Cookie/Set-Cookie - used to turn HTTP into a stateful protocol Authorization/WWW-Authenticate - used to transmit information about the relationship between the client and server.

Well, I think you'd want to think carefully before pulling things out of HTTP and forcing HTTP to sit on top of a stateful, session-based protocol in order to achieve them.

The statelessness of HTTP is one of its major strong points, making it easy to load-balance and scale, more easily compatible with a wide range of middleware, etc. The redundancy involved in repeating certain headers is a design trade-off made for a reason.

There's a bunch of trade-offs here in the protocol design though, evidently. Coming at it from a security perspective seemingly leads to a different view of those tradeoffs than (say) Fielding has.

If you have an application with a really pressing need for stateful session-level protocol features though -- perhaps HTTP isn't the best choice anyway?

User-Agent is far from useless. When filling out support forms wouldn't you rather skip all the annoying questions about your OS and browser?

Good point - it's become the de-facto way of communicating client capabilities to the server.

It's often the best choice for authenticating these

SAML is a better auth mechanism for REST services.

HTTP Authentication is dead and is never coming back.

What should WebDAV shares use instead? I don't think form auth really works for that.

WebDAV is a good point but may be the exception that proves the rule, since it is itself such a misfeature. Meanwhile, mentally amend my assertion to "HTTP authentication for browser-based web applications is dead and is never coming back".

I've never understood whats so "ugly" about http authentication. Digest auth can get a little verbose, to be sure, but Basic+SSL is simple, and both are far easier than roll-your-own Cookie auth. In fact, the way most people & frameworks implement cookie auth sessions are no less secure than Basic auth. Haven't the events of the past week demonstrated we should all be using SSL anyways, in which case Basic auth would be fine for everyone.

A few problems with basic auth:

    * Browser specific UI, which leads to:

      * No place to put password recovery links

      * No place to put explanatory text

    * No mechanism for logout

If the browsers would allow the login box to be styled via CSS like the rest of the UI, I think you would see more use. We finally went to SAML for our REST service authentication and have been pretty happy with it. THe nice part about SAML is an identity server provides the auth endpoint, and your app proxies the token to the identity server for authentication and authorization, it gets your app or container out of the game of authentication and authorization. Further many app servers can plug into the identity server therefore providing container managed security gates.

Basic auth is only simpler than cookie auth if you (a) aren't using a modern web stack (ie, you aren't using ASP.NET, J2EE, Rails, Django, &c) and (b) have only a few users.

If either (a) or (b) do not hold, Basic Auth is at least as hard as cookie auth.

I use HTTP authentication when I want to password protect a bunch of static files, or a third party web app. Using the PAM auth module with Apache is particularly nice. Just drop a few lines in a .htaccess file and it uses your users system credentials, eg /etc/passwd and /etc/shadow.

HTTP Authentication comes in several flavours. I've not done it myself, but I think you can do interesting things to with Kerberos. Good for Intranet systems.

HTTP Authentication does have its places.

In other words, HTTP Authentication is useful in the same sense as FTP is useful: it's outmoded but sometimes convenient.

HTTP Authentication is sessionless. In any scenario where you want to protect something without establishing and maintaining a session, it's useful.

The only large public website that I know of which still uses HTTP Authentication though is http://www.123-reg.co.uk/

What's the browser app scenario in which having a session is a liability, but having a stored HTTP Auth credential isn't?

Actually the elimination of server side session reduces distributed application topology significantly. It is far easier to scale a stateless app than it is a statefull app.

But if your clients include things that aren't browsers, HTTP Auth is the only acceptable choice.

That's not true either; you can just do what big API apps do and generate access tokens. Amazon Web Services don't rely on HTTP-Auth.

Using curl to access AWS is kind of a pain, since you have to hash the body and your keys into a header. For others, you have to set the token in a header, and it (should) change periodically.

Compare to:

    curl --anyauth --user login:password https://example.com/

It's a "1 line of Python" pain, true, but it's also significantly more secure. From a cost/benefit perspective, it's an API, a building block of a software development project, and optimizing it for curl-ability doesn't seem like a major win.

But my point is just: HTTP Auth is not the best-practices answer to non-browser web services auth. Both API-key and signed URLs are both competitive (and probably better) options.

What about for SSL-based APIs? it seems a pretty optimal choice for those.

I don't think it is, for two reasons:

(1) For most large apps, you're not really SSL in the provider's own network, so there's always the cross-app risk if something horrible happens.

(2) It's forcing app-to-app, business-to-business authentication into a username/password mold that doesn't many any real sense; a 128 bit random key (or an SSL client cert) makes more sense anyways.

Against those two problems --- which are marginal, I concede --- HTTP Basic offers... exactly what advantage? I don't see it.

Reply on news.ycombinator.com