Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Answer: Security: Cookies vs HTTP authentication

( #31297=categorized answer: print w/ replies, xml ) Need Help??

Q&A > CGI programming > Security: Cookies vs HTTP authentication contributed by Fastolfe

If you're already authenticating with HTTP authentication, I would stick with that rather than writing a bunch of state management stuff with cookies. This is all handled by the web server with HTTP auth, so I would see about protecting a subdirectory under /cgi-bin/ or reconfigure the server so that you can run your protected CGI scripts under the directory that you already have protected. I have never understood why sites insist on using all sorts of complex state management code and cookies with "authenticated" sessions when HTTP authentication will do all of this for them, giving the CGI script a nice friendly environment variable with the username. Plus you don't have to worry about invalidating URL's or having obfuscated keys showing up in access/referer logs for your server or sites you link to. It's all just a big headache, and unless you find a quality pre-written installation, it's not worth it. Stick with some form of HTTP authentication and you'll have much less headache. Of course, either mechanism, as another poster mentioned, is susceptible to monitoring by a 3rd party, which is why you'd want to use SSL if you're concerned about this. Unless you're trafficking sensitive data, I wouldn't worry.

Comment on Answer: Security: Cookies vs HTTP authentication
RE: Answer: Security: Cookies vs HTTP authentication
by merlyn (Sage) on Sep 06, 2000 at 22:13 UTC
    Cookies permit two separate sessions to be tracked even using the same authentication though. I might be merlyn with two separate shopping sessions going on, one for stuff I'm buying for work, and one for stuff I'm buying for the house.

    Also, BasicAuth requires two trips to the server for each page, whereas cookies come up for free on the first hit, so server load is much lower with cookies. Ideally then, I'd authenticate using BasicAuth, and then a time-limited cookie gets thrown at me while I wander through non-authed (but cookie protected) pages.

    Finally, every BasicAuth is transmitted in the clear, so this gives a sniffer that many more times to see the password. Do you really want your password being transmitted in the clear for each and every hit, or just once at the beginning of a session (perhaps in SSL) and then the rest of the session transmits just a session cookie? In fact, that'd be interesting to set two cookies, one that is used to track the shopping cart, but a completely different SSL-only cookie that is used for final checkout, so that the worst someone could do is put stuff in the cart, but not actually buy it. Hmm. Nice idea. I'll have to make a column on that. {grin}

    -- Randal L. Schwartz, Perl hacker

      I'm not sure what browser you're using where each authenticated page request requires two hits, but IE will send authentication information for all subsequent hits in the same area without being asked. The first request obviously is rejected on the grounds that no authentication information is provided, but after that the browser should know to send it automatically. You are correct about the fact that with one "session key" (being the username), only one session can be active (two browsers going to the same place share state information). In many cases, this is acceptable, but if you want separate state information, a session key is desirable. The advantage here, though, is that the session key need not be cryptographically secure. All it needs to do is distinguish between one instance of a user and another. At least, that's how I would code it. Another user trying to use the same session key would be noticed by the script as someone else trying to use another person's key, or as an invalid key (since that key doesn't exist on the system for that user; each key would be "local" to that user.. *shrug*). Implementation is up to the coder.

      As far as going back and forth between authenticated and unauthenticated portions of the site, you wouldn't even need to tag them with a cookie for unauthenticated portions. The moment they follow a link back into the protected area, their visit is authenticated again (silently) and if you specify appropriate path information for the cookies, the cookies get sent again. If you're concerned with their identity for pages X Y and Z, make those pages protected if you can.

      I'm not saying HTTP authentication is always better than using cookies, but in many cases it's overlooked for whatever reason, and I was just trying to point that out.

        I'm not sure what browser you're using where each authenticated page request requires two hits, but IE will send authentication information for all subsequent hits in the same area without being asked. The first request obviously is rejected on the grounds that no authentication information is provided, but after that the browser should know to send it automatically.
        I think you're mixing up cookies and auth here, or perhaps the caching of auth performed by a browser. A browser is not supposed to sent auth unless challenged. IE remembers that you auth'ed in an area (against a particular realm name), and resends its stored auth in the same area, but it can't know which auth to send until it gets a challenge with the realm name. And it can't get the challenge unless it sends it without auth the first time.

        I just verified this in a basicauth protected area of my website. iCab gets it right, waiting for the challenge on each hit. And yes, NS and IE both do it wrong, sending an auth before being challenged. How sucky. How do they know which realm to send up? Or do they just do the most recent realm? That could be a security hole.

        Ahh, RFC2617 agrees with both of us {grin}:

        A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server. Similarly, when a client sends a request to a proxy, it may reuse a userid and password in the Proxy-Authorization header field without receiving another challenge from the proxy server. See section 4 for security considerations associated with Basic authentication.
        Hmm. I did not know the preemptive auth send. Thanks for pointing that out to me.

        -- Randal L. Schwartz, Perl hacker

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (11)
As of 2014-11-23 16:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (134 votes), past polls