I kind of expected this response, and the style of writing may be a little provoking, but I think it's a pretty factual assessment of where these projects are headed. Feel free to disagree, though.
glad you expected the response -- you're a classic troll; complete with creating a dummy account, the opening line
stating a stupidly absurd negative comment, and the closing
line with the insinuation that the devs go through all the
pain of running a project for their own edification
LinkedIn is one of the sites that limit the length
of your password and what it can maintain. I've
emailed their staff many times, and they simply
respond that those are the password restrictions.
The alternative track is 'research scientist'. That's the title where you get to play on the company's dime. Unfortunately, it usually requires a PhD and have a strong publication history.
Yeah. That's way not me. Not really interested in playing, anyway. Would rather ensure that I work someplace that's run well so I can go home and play with a clear conscience.
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.
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.
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?
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.
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.
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.
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.
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.
(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.
The mountains and Inca ruins are absolutely stunning;
even in July it should be quite temperate there (it
doesn't really freeze), but, since it's winter, it
won't be hot so you'll need a modestly warm jacket.
I think frameworks have to be engineered carefully; the use of the strategy pattern in the example is a typical and is very soundly used in a framework. I think the problem is that developers write far too many frameworks than they should. Interestingly enough, it's code that isn't extensible that ends up being a framework -- mostly because the authors have time to focus on documentation, support, user interface and the like.
