On Thu, Jul 8, 2010 at 1:00 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > On Thu, 2010-07-08 at 09:53 -0700, Michael Calkins wrote: > > > I right now have a complete user login and registration system however it > uses cookies when you login to store information. Is this a bad > thing?$_COOKIE vs $_SESSION for login systems > > > > From,Michael Calkinsmichaelcalkins@xxxxxxxxxxxxxxxxxxxx > > > > > > _________________________________________________________________ > > The New Busy is not the too busy. Combine all your e-mail accounts with > Hotmail. > > > http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 > > > VERY bad idea! :p > > Basically, cookies should only be used to store general non-personal > information. Sessions are for anything that you want to keep out of > prying eyes. The reason being is that cookies are just plain text files > on the client machine, and can effectively be read by another program or > person very easily. > > Sessions make use of cookies to store the session_id whilst a user is > logged in, but you should destroy the session after you no-longer need > it to remove the chance of someone getting hold of it and spoofing a > request to your server. This can be done by destroying the session when > a user logs out and setting a default timeout on a session. > > Sessions are easier to use I've found than cookies. You can add > information to the session and read it right back without need the > clients browser to make a new request to your server with the updated > cookie in the header. You can store far more information in a session > (exactly how much more depends on your server setup obviously) and in a > much more logical manner than a cookie. > > This is not to say that cookies don't have their uses, but I think for a > login system they introduce potential security issues which can be > exploited. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > Hi Michael, The short answer is that it depends. Cookies are not inherently bad. Cookies are simply another piece of text that's sent to and fro from client to server (via "Set-Cookie: name= value" and "Cookie: name=value" exchanges), and this particular piece of text has a special storage mechanism integrated into most web browsers. Since it's inception, cookie support has improved significantly on browsers, as the security policies now in place provide much more security than those first implemented in the olden days. Today, cookies are a valuable tool used to facilitate the vast majority of website login mechanisms. PHP uses cookies to track sessions of web visitors (the cookie stores the corresponding PHPSESSID), and these sessions are often used to handle auth checks. That is, unless you've set your PHP environment up to propagate the session id through the url, which is not usually wise as it's quite easy to expose the PHPSESSID in server logs as through the referrer header: http://php.net/manual/en/session.security.php ASP.Net uses cookies to handle the provide the forms-based auth mechanism, storing limited session information directly within the cookie itself: http://msdn.microsoft.com/en-us/library/ff647070.aspx#pagexplained0002_aspnetforms I right now have a complete user login and registration system however it > uses cookies when you login to store information. Now, the questions I'd have for you are: - Are the cookies merely storing the auth tokens or is other information being stored? - If other information is being stored, what type of info is it, how secure does it have to be, and how many bytes of data is it. Whatever scheme you're using, if you're exchanging the cookie over a non-secure channel (i.e., not using HTTPS), you're application is vulnerable to session hijacking: http://en.wikipedia.org/wiki/Session_hijacking I have stored limited amounts of information in the cookie (e.g., default stylesheet info, user first name, etc.), and when I wanted to protect the information, I signed and encrypted it. Because of the nature of a cookie, you'd have to guard against replay attacks even if the information is encrypted: http://en.wikipedia.org/wiki/Replay_attack In summary, a cookie is merely a tool for persisting data on the client. It can facilitate great security, but it's contribution (or detriment) to the security of your application depends on how it's used. Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
