Cookie / Session Based Authentication vs HTTP Authentication
July 19, 2005 7:59 PM Subscribe
How come most websites roll their own authentication methods around cookie-based sessions, rather than using http authentication built in to most web servers? Is this a security issue, or a user interface issue? Or something else?
You could fairly easily automate a brute force hack on an htaccess protected site, due to the following syntax:
http://username:password@www.website.com/
However, beyond any security and aesthetic considerations, I believe handling the authetication directly is the only logical way to have things like preferences, account profiles, etc. in your web application.
posted by o0o0o at 8:19 PM on July 19, 2005
http://username:password@www.website.com/
However, beyond any security and aesthetic considerations, I believe handling the authetication directly is the only logical way to have things like preferences, account profiles, etc. in your web application.
posted by o0o0o at 8:19 PM on July 19, 2005
o0o0o: Your standard vanilla login form is nearly just as easy to brute force. Also, your web app can check the environment variable REMOTE_USER that the server will set, and this can be used to have prefs, profiles, etc.
Anyway, mostly it comes down to interface asthetics.
posted by thebabelfish at 9:12 PM on July 19, 2005
Anyway, mostly it comes down to interface asthetics.
posted by thebabelfish at 9:12 PM on July 19, 2005
Right.
Of course environment variables have had their own problems and you're leaving a critical piece of security completely up to the web server.
While I'm sure you can find ways to do many things with htaccess, there is no logical reason to detach the actual authentication process from your application, unless you're being lazy or you're not overly concerned about protecting your data.
If your application does anything with user accounts, beyond saying "ok, you can see this directory", then you're going to need to do some serious ugly hacks. Even allowing (god forbid forcing) a user to update their password would require quite a bit of scripted duct tape.
The bottom line is -- handling the authentication process yourself allows for tighter integration and a finer level of control. If you're doing anything half way serious, don't use htaccess as your only source of authentication.
If you're looking for more information, SecurityFocus appears to have a good three part article on the problems with using htaccess and how to make it more secure:
Part 1, Part 2, Part 3.
posted by o0o0o at 9:57 PM on July 19, 2005
Of course environment variables have had their own problems and you're leaving a critical piece of security completely up to the web server.
While I'm sure you can find ways to do many things with htaccess, there is no logical reason to detach the actual authentication process from your application, unless you're being lazy or you're not overly concerned about protecting your data.
If your application does anything with user accounts, beyond saying "ok, you can see this directory", then you're going to need to do some serious ugly hacks. Even allowing (god forbid forcing) a user to update their password would require quite a bit of scripted duct tape.
The bottom line is -- handling the authentication process yourself allows for tighter integration and a finer level of control. If you're doing anything half way serious, don't use htaccess as your only source of authentication.
If you're looking for more information, SecurityFocus appears to have a good three part article on the problems with using htaccess and how to make it more secure:
Part 1, Part 2, Part 3.
posted by o0o0o at 9:57 PM on July 19, 2005
These days, I typically use the cookie or session control string method and integrate it into the application. PHP does this seemlessly for me, and once authenticated, you can attach seemingly rather complex data structures to a user's session.
Having said that, there was one thing I thought that Microsoft did right back in the old days (*gasp* Yes, I said it). No matter your method of authentication in a MS environment, when dealing with VBScript on the server side, you were always dealing with the same objects. When we moved from http authentication to an integrated system, and then later to an LDAP-based system, we never had to change the underlying code that worked with the permissions object. The permissions object was always the same API, irrespective of your external methods of confirmation.
But, back on track: The typical reason that I can give, from a programmer's standpoint is total integration. You never want to have to maintain a separate .htaccess/.htpasswd or groups file from your main application. That's just a nightmare crouching on your desk, leering over your shoulder, or otherwise winking at your menacingly from the corner of your office.
posted by thanotopsis at 10:32 PM on July 19, 2005
Having said that, there was one thing I thought that Microsoft did right back in the old days (*gasp* Yes, I said it). No matter your method of authentication in a MS environment, when dealing with VBScript on the server side, you were always dealing with the same objects. When we moved from http authentication to an integrated system, and then later to an LDAP-based system, we never had to change the underlying code that worked with the permissions object. The permissions object was always the same API, irrespective of your external methods of confirmation.
But, back on track: The typical reason that I can give, from a programmer's standpoint is total integration. You never want to have to maintain a separate .htaccess/.htpasswd or groups file from your main application. That's just a nightmare crouching on your desk, leering over your shoulder, or otherwise winking at your menacingly from the corner of your office.
posted by thanotopsis at 10:32 PM on July 19, 2005
Response by poster: thanatopsis -- I agree that seperation would be a pain, and yet there seem to be some relatively easy solutions to the problem, from mod_auth_(my|pg)sql to having the .htpasswd file generated/updated via your application.
oOooOo -- thank you. That's the security angle I was looking for. I'm not really convinced that leaving some aspects of security up to the web server is a bad thing, given the fact they're almost certainly better reviewed than custom web apps and possibly even the application server and frameworks on which they're based. But knowing what can go wrong with apache's authentication and similar models is good stuff.
posted by namespan at 11:12 PM on July 19, 2005
oOooOo -- thank you. That's the security angle I was looking for. I'm not really convinced that leaving some aspects of security up to the web server is a bad thing, given the fact they're almost certainly better reviewed than custom web apps and possibly even the application server and frameworks on which they're based. But knowing what can go wrong with apache's authentication and similar models is good stuff.
posted by namespan at 11:12 PM on July 19, 2005
For me it's all about logging out, which is a pain to handle with HTTP auth. Also, with sessions you can be logged in from multiple locations and have different session data, which can be handy.
posted by revgeorge at 5:18 AM on July 20, 2005
posted by revgeorge at 5:18 AM on July 20, 2005
For me, the biggest reason to use cookie/forms-based auth is the timed log-off. That is. if the auth module is built to invalidate the cookie after N hours, than a careless user might leave an open web browser window with e.g. their mail on a computer and walk off, and after the cookie expires nobody will be able to read their mail or compose new mail or what have you. This functionality is incredibly difficult to achieve with HTTP basic auth - it'd require a ton of extra code on the web server that would do nothing short of actually breaking the RFC functionality.
As revgeorge points out, non-timed log-off is another very useful feature.
Finally, forms based auth allows specification of different credential formats and credetnails stores, should this be desired. Suppose you are building a shopping cart, and you want to give return customers a login/password. With http basic auth you'd have to either create real accounts for them in your computer/directory, or use a .htaccess/.htpasswd type of hack which suffers from extreme lack of manageability. With cookie auth, you can write a little piece of code to go against an e.g. SQL database of names, or an XML file, or whatever else you dream up. While you could make HTTP basic auth do the same by plugging into the web server processing timeline (with an IIS ISAPI filter or apache module) the degree of difficulty will probably be far greater than customizing an existing forms-based solution.
posted by blindcarboncopy at 10:55 AM on July 20, 2005
As revgeorge points out, non-timed log-off is another very useful feature.
Finally, forms based auth allows specification of different credential formats and credetnails stores, should this be desired. Suppose you are building a shopping cart, and you want to give return customers a login/password. With http basic auth you'd have to either create real accounts for them in your computer/directory, or use a .htaccess/.htpasswd type of hack which suffers from extreme lack of manageability. With cookie auth, you can write a little piece of code to go against an e.g. SQL database of names, or an XML file, or whatever else you dream up. While you could make HTTP basic auth do the same by plugging into the web server processing timeline (with an IIS ISAPI filter or apache module) the degree of difficulty will probably be far greater than customizing an existing forms-based solution.
posted by blindcarboncopy at 10:55 AM on July 20, 2005
This thread is closed to new comments.
I don't use cookies, though, I use a session id that is passed in the URL.
posted by trevyn at 8:06 PM on July 19, 2005