Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Security: Cookies vs HTTP authentication

by rodry (Beadle)
on Sep 02, 2000 at 00:36 UTC ( #30806=perlquestion: print w/replies, xml ) Need Help??

rodry has asked for the wisdom of the Perl Monks concerning the following question:

I have a private area in a website that I protected using HTTP authentication. That is, I password-protected a directory and its files.

However, I did not realize that since the pages in that directory call scripts from /cgi-bin (which anyone can access), that those pages are not really that secure.

Which raises the question, for which situations are cookies a better choice than HTTP authentication and viceversa.

Thanks in advance.

Originally posted as a Categorized Question.

  • Comment on Security: Cookies vs HTTP authentication

Replies are listed 'Best First'.
Re: Security: Cookies vs HTTP authentication
by vaevictus (Pilgrim) on Sep 02, 2000 at 01:01 UTC
    cookies and HTTP authentication are not really very secure either of them... you can always hack around their code... and it's sniffable.

    HTTPS is much better...

    To elaborate more, cookies are not any form of authentication, inherently, because they're just client stored variables. Anyone can have them, edit them and change them. You could encode some sort of key and try try to keep track of the users' sessions or just the users themselves. You are still going to have to do some sort of login technique. If I'm not mistaken, HTTP authentication sets cookies anyway.

    If you're worried about "security" you'll need to subdivide "security" by what you're worried about. If you need to be sure that a user says he's who he is, you'll need to use some sort of cryptography and authentication technique. If you're going to have content that 3rd parties cannot see, you'll have to invest some time and/or money or both into HTTPS. If you're worried about someone rooting your box, you'll have to be very careful with your scripts, global variables, and even your webserver setup and version.


    Security is not a goal, it is a way of Life.

Re: Security: Cookies vs HTTP authentication
by Fastolfe (Vicar) on Sep 06, 2000 at 22:04 UTC
    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.
      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.

Re: Security: Cookies vs HTTP authentication
by rodry (Beadle) on Sep 02, 2000 at 01:11 UTC
    How about sites that don't use HTTPS and still have some sensitive information that they secure by means of cookies.

    Take for example www.egroups.com. You store sensitive information about yourself and the poeple in your group. Not to mention pictures, resumes, etc. Yet I don't remember having to go thru a HTTPS secured page to login or authenticate.

    That kind of security is enough for me. What do you think.

      For me, it is instinctive, reflexive and otherwise just subconscious to glance at the little padlock in the lower left of the Netscrape window before I even type something I consider sensitive into a browser window.

      I say this because you do not have to log in to be using https. Don't confuse SSL with security. SSL simply means "reduced risk of eavesdropping." Nor does logging in imply https. You could have logged in, then been dropped back out to a "normal" protocol.

      Further, it may be nearly impossible to know what egroups or anyone else is doing "behind-the-scenes." You may have logged in through an https page, and they are now ignoring that authentication information when they determine what data you may and may not view. If they use only cookies or CGI parameters to determine what you may access, their entire site, and all data in it, is probably up-for-grabs to anyone who wants to get it.

      So, IM(ns)HO, using the words "cookies" and "security" in the same context is fundamentally bogus. As to whether that level of security is enough...to each his own. As long as you do not put truly sensitive data on the site, who cares? If you store, on a site secured by cookies or CGI params only, anything you do not consider public knowledge, you are gambling against long odds. Pure and simple.

      Good luck. :-)

      Russ
      Brainbench 'Most Valuable Professional' for Perl

      IMHO, Securing "by cookies" is not securing at all... if you have not done some sort of user/password or crypto key exchange, then I'd be really worried about doing anything with www.egroups.com.
      It sounds like to me, that it would be pretty easy to obtain the data on egroups by inappropriate means. (Logging in as someone else.) I mean... the server can store data on your computer in those cookies... but all that says is "someone once connected here". Unencrypted cookies can be sniffed. Then they can be used *EASILY* by anyone with a 3rd grade hacking level.

      Thanks for the heads up on egroups though... i'll prolly avoid them now. :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://30806]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (2)
As of 2022-08-11 04:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?