sessions vs cookies

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply

sessions vs cookies what is more secure??

Poll ended at Wed Jun 25, 2003 4:10 pm

sessions
10
83%
cookies
2
17%
 
Total votes: 12

User avatar
m@ndio
Forum Regular
Posts: 163
Joined: Fri Jun 06, 2003 12:09 pm
Location: UK

sessions vs cookies

Post by m@ndio »

what is more secure??

Have your say..
User avatar
delorian
Forum Contributor
Posts: 223
Joined: Sun May 04, 2003 5:20 pm
Location: Olsztyn, Poland

Post by delorian »

It's obvious that sessions are more secure, they give you more ways to make your site safe. But of course there's always a way to hack in. :D
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Neither method is more secure.

Sessions are implemented using either cookies or GET. So sessions can't be more secure than cookies. Sessions appear slightly more secure because they only need to transfer one bit of data to/from the client. Therefore more of the required variables are hidden from the client. However, the default sessionid is easily hijackable.

For better security you need to roll-your-own session-handling using a MAC'ed cookie to transport the sessionid to from the client. For another layer of security mcrypt the cookie before you send it and decrypt it on receipt or use SSL.
User avatar
delorian
Forum Contributor
Posts: 223
Joined: Sun May 04, 2003 5:20 pm
Location: Olsztyn, Poland

Post by delorian »

nielsene wrote:For better security you need to roll-your-own session-handling using a MAC'ed cookie to transport the sessionid to from the client. For another layer of security mcrypt the cookie before you send it and decrypt it on receipt or use SSL.
Could you provide me some more info about stuff above, some articles etc. In php.net I can't find anything about it. But maybe I didn't search good enough :D
m3rajk
DevNet Resident
Posts: 1191
Joined: Mon Jun 02, 2003 3:37 pm

Post by m3rajk »

delorian: the write up on sessions say that there are actually a set of ways it works, starting with embedded information, and ending with cookies. this means that you can't call it more secure. in both styles security is what else you add. i looked into that already for the site i'm building. personally i think it's easier to use cookies straight out (although it required the user to have them turned on) because it remoes the information from immediate view since most people wont be notified on cookies bounced back to the originating server.

if you really want to make it harder for the person to see, you can mask the cookie's information with mcrypt as neilson suggested, and if you want security, as he told me in a previous thread, use md5 to encode it.
that still does nothing about the fact someone can watch.. yet cookies have ssl as a thing you can require. that should remove that, hence why i feel it's better to use cookies... you're more aware of the level of security since it wasn't automated by php.
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

Yes, exactly what m3rajk said.

Sessions are wonderful, wonderful things, because they make things very easy for us developers. However, at some point in your programming life its critical to understand exactly how any given peice of code works.

The quick and dirty view of sessions is that they stored all the session variables for a given person in a file indexed by the PHP generated session id. The user's browser is responsible for somehow providing your server with this id on every page view. (HTTP is a "stateless" protocol, this means that there is no way for the server to know that two requests are coming from the same person, we have to somehow "trick it" into carrying state around.)

The simpliest way is to stick variables in the URL aka GET (?phpsessid=asdfksadf). However, many people feel this makes ugly URLs. It also make it easier for the user to "mess with" the session id. You can also stick the session id in a hidden form element, but that will then require all your pages to use form-buttons to navigate. Cookies are the next option. A cookie is a little file sent to the browser by the server. Browsers "know" to send the cookie back on every page view to the server that issued it. Users can still "snoop" around in their browsers "cookie jar" to find and edit cookies. All PHP does is automate the use of one of these methods for sessions. Typically it tries to use cookies first, and then fallback to GET.

I think PHP has made it a little too hard to truly "secure" a session and while I still use them I plan to write my own session library "soon". You can see some of my "testing" work in a thread here.

The security tools I talked about mcrypt and MAC'ing:
mcrypt is an encryption library (check out http://php.net/mcrypt for more information on it). It is a collection of two-way, secret key algorithms. This means that you can encrypt and decrypt something. This is useful for "hiding" sensative information. For instance you might want to encrypt the session cookie before sending it, even if using SSL, to hide the cookie's data from the user. Also you might want to encrypt sensative information in your database, such as cc#'s, or phone-numbers, if you don't need to search on them to often and want to protect your user's privacy.

MAC'ing (Message Authentication Code): are used to check if something has been tampered with. Typically speaking MAC'ing uses a one-way hash, such as MD5 (use php's MD5() function). What you do it you MAC the value with a secret and then append the MAC to the value. You then send the whole composite as the message. If anyone tampers with the value, when you get it back and re-MAC it the values won't match and you know to reject the data.

E.g.

Code: Select all

$data="Foo";
$mac = MD5($data."SECRET STRING");
$data = $data . "+" . $mac;
// send cookie with data payload
...
// get cookie back on later page
$data = $_COOKIE["data"];
$crumbs = explode("+",$data);
if ($crumbs[1]!=MD5($crumbs[0]."SECRET STRING"))
{
 // reject data, attack in progress
}
else
{
  //safe
}
Does this answer your question? (And probably raises many more :) ) For more about encyption and its uses check out http://rsasecurity/rsalabs/faq/
User avatar
delorian
Forum Contributor
Posts: 223
Joined: Sun May 04, 2003 5:20 pm
Location: Olsztyn, Poland

Post by delorian »

A little :D But I new about the mcrypt, and thought that MAC'ing was something else - like getting the MAC Address of the user physical device if that could be possible to retrieve in script it could be great.

But what you gents taking about is true and I must admit that you got me confused a lot. :D In sessions I use a simple and similar sollution to nielsene's MAC. I've a md5( of session_id + random_string + ip_address) check on every page. The value of it with the random_string is also written to some temporary file on the server. Random_string is a md5 value from entry statistic. If somebody steal the cookie, and even spoof the IP it also have to know some other info about the user which he left in my stat.

But of course, I read what you wrote here and I will think about something more to better secure my site. Thanks a lot gents.

BTW: I still can't use cookies because some people have set no-cookies for every page :D :D so sessions is a must.
Post Reply