Is PHP Session more secure or SetCookie?

Question

What bit is more secure?

   function login_customer($customer_details) {
    //Set a cookie to login the customer
    setcookie("Str_CUST_LOGIN", 1, time()+3600);
    setcookie("Str_CUST_EMAIL", $customer_details['customers_email']);
    setcookie("Str_CUST_ID", $customer_details['customers_id']);
    //Update the cart
    return true;
}

or is this below. The script uses IF ELSE statements. Nightmare application for old client.

   function login_customer($customer_details) {
    //Set a cookie to login the customer    
    $str_HA_CUST_LOGIN="1";
    // the customer details var gets info from a mysql escape form
    // so mysql /xss is stopped
    $str_HA_CUST_EMAIL=$customer_details['customers_email'];
    $str_HA_CUST_ID=$customer_details['customers_id'];

    $_SESSION["loggedIn"]=$str_HA_CUST_LOGIN;
    $_SESSION["userEmail"]=$str_HA_CUST_EMAIL;
    $_SESSION["userID"]=$str_HA_CUST_ID;

    return true;
}

I am trying to improve it and lock sessions down. Not done any Salt, MD5 based sessions strings yet as I was thinking of a database session - only issue here is MySQL is so overloaded we had to make a master and cluster load balancer on cloud servers. 200+ average orders per second on a quite day. So I want sessions??

Session is more secure, it is stored on server side, a cookie just informs to server what is your session ID. Store data in cookie is unsecure and too much limited (you can store only 4kb) — David Rodrigues, Nov 28 '11 at 15:58
Use: http://stackoverflow.com/questions/36877/how-do-you-set-up-use-httponly-cookies-in-php — user956584, Nov 28 '11 at 15:58
PHP seems to feel more unsecure everytime I read about these articles. Why the down vote? What is the point making session and setcookie functions within the programming langauge when they are insecure - why did they bother making it ??? — TheBlackBenzKid, Nov 28 '11 at 16:04
Stop down voting me. Consider a comment or answer - that is what the UI prompt is. I habe not posted all the code @Rook - let me ask you: If I post a question showing all my code and variables and SQL password commands - is everyone going to have a peak to see? Obviously. In this situation, I have not posted the Password parts. — TheBlackBenzKid, Nov 28 '11 at 16:30
Thanks for your comments. I think I will go with having a cookie, and a session lock. That way, the IF ELSE statements will check both and I might even do a salt. — TheBlackBenzKid, Nov 28 '11 at 17:18

score 5 · Accepted Answer · answered Nov 29 '11 at 13:42

Cookies can be easily forged and tampered by a client. So if an attacker knows what cookies the application expects, he/she can forge the cookies or alter the cookie values at his/her will.

In your case it would probably be possible to authenticate as a arbitrary customer solely on the basis of knowledge of the customer ID (and/or the e-mail address).

The problem with this is that you mix up identification (‘Who is the user?’) and authorization (‘Can he/she prove it’s really him/her?’). Because both an ID and an e-mail address are used for identification as they are both unique and some kind of public (i. e. not just known to you) and thus not qualified for authentication. So don’t use identification information for authentication as well.

Now if you think I’ll just put the password in a cookie as well that would fulfill the authentication aspect, don’t do that either. Because there are attacks where an attacker can read the contents of a cookie (e. g. Cross-Site Scripting) and thus would be able to obtain the authentication data.

Use the session container instead to store the sensible information on the server side. But with sessions you still need to be aware of session related attacks like Session Hijacking or Session Fixation.

Why do you keep saying he/she. Just say user and stop being dramatic. Great post. The session hijacking info is what I needed. Marked as answer for constructive feedback and good approach for solution. — TheBlackBenzKid, Nov 29 '11 at 17:34

score 1 · Answer 2 · answered Nov 28 '11 at 16:00

Cookies and their data are sent over the wire on EVERY request to the page. If you're embedding site-critical data in the cookies, it will be trivial to mangle/steal that data while the page requests is "in flight".

Sessions, by comparison, store all data on the server. The only thing that goes between the client and the server is the session's ID token. Stealing the session token allows an attacker to assume the victim's identity, but then they don't gain any more abilities than the user had already.

e.g. If you're sending out a cookie has_super_user_powers=false, then don't be surprised when someone hacks the cookie to make it true instead. Saving that flag in the session makes it unchangeable by the remote user, as the value never leaves your server in the first place.

Basically your saying here: Use Database MySQL?? - this is not an option. — TheBlackBenzKid, Nov 28 '11 at 16:04

score 0 · Answer 3 · answered Nov 28 '11 at 16:01

Both can be stolen, but the value of cookies can be read. Sessions can contain more information.

Both are equally as safe, but to properly use cookies you'll have to spend a little bit more time.

If you're just starting with session management, just use sessions.

-edit-

Actually, technically cookies are more secure than sessions are. Since sessions are based on cookies they can only be as secure as cookies are, and almost always less secure than that. However, unless you have a very good implementation, sessions will be safer for you.

score 0 · Answer 4 · answered Nov 28 '11 at 16:01

Depends on what kind of information you store in those cookies. But Sessions in general are more secure than cookies. Since cookies reside on the clients machine, while sessions are on your server.

If your server is already overloaded, better not use a database based session. Either use file based sessions (default per PHP) or the data you want to store is irrelevant, feel free to use cookies instead.

Is PHP Session more secure or SetCookie?

4 Answers4