$_COOKIE

[Bryce910]

Is it bad practice to use $_COOKIE for your log in system and to protect your pages or would it be better to use $_SESSION?

 

I have always used cookie but I am not sure if that is good practice

[Jessica]

Cookies enable users to stay logged in after they close their browser. Sessions do not.

Cookies can be edited by a user.

Cookies can be "grabbed" by another website and allow someone to spoof another user's account on your website. There are ways to protect against that, you should be able to find some info via google.

 

A combination of both is best, but either one needs logic on your end to prevent problems.

[ManiacDan]

A couple more things:

 

The session is controlled by a cookie.

 

Due to this, the session CAN extend past a single browser session, but it's usually unwise to do that.

 

You should NEVER keep information in a cookie that would be bad if a third party received it.  Never keep personal information, payment information, passwords, or anything else in the cookies.  Also, never ever use a cookie for the user's security role.  If you have a cookie called "is_admin," you've done it wrong.

 

What you should be doing is simply using the session for everything.  If you need to do auto-logins or "remember me" cookies, they should be set to a relatively short duration (2 weeks is standard) and contain a hash of the userID, user-agent of the browser, IP (if you want), and some secret information available only to your database, like the user's exact create date.  That way, nobody can spoof that cookie.  So you'll store an auto-login-hash cookie, as well as a user-id cookie.  When they go to your site and they don't have the session, but they do have those two cookies, use the user-id cookie to look up the information that should be in the hash.  If the cookie hash matches the data you pull from the database and the $_SERVER variable, you can log them in.

[xyph]

I agree, but I didn't know outside domains could "grab" cookies. I know via XSS it's possible, and that it creates potential CSRF attacks, but otherwise? Please elaborate.

 

For the remember me cookie, all of ManiacDan's advice is great, but I'd like to add that you should have a cryptographically-secure random number added in to that. If it's just dates, ids, user-agents and IPs, there is potential to predict current and future tokens for any given user.

[ManiacDan]

I think CSRF is what she meant, there's no "legitimate" way it's supposed to happen, but it happens.

 

For the remember me cookie, all of ManiacDan's advice is great, but I'd like to add that you should have a cryptographically-secure random number added in to that. If it's just dates, ids, user-agents and IPs, there is potential to predict current and future tokens for any given user.

That's why I put the user's create-date as part of the one-way hash.  You can't tell what data is in there, and one of the pieces is never available to the user. 

[xyph]

I understand the obscurity of the data, but it's still guessable and static. Give a smart person enough pieces (with open sign-up, they can get lots) and they'll start putting it together.

 

PHP pseudo-random generators are seeded with calculations that include timestamps to the millisecond, but they're still considered predictable.

 

On a scale of entropy, I don't believe all of your suggestions combined amount to a 128-bit string of cryptographically-random data.

 

I only push it like this because of the speed and ease of use for /dev/urandom, and it's now-existent Windows equivalent. As of PHP 5.3, and later versions of Win/WinServer, the MCRYPT_DEV_RANDOM and MCRYPT_DEV_URANDOM constants will work on Winboxes when using mcrypt_create_iv

 

I just don't see why you wouldn't want to include some for of random seed in your token

[ManiacDan]

I just don't see why you wouldn't want to include some for of random seed in your token

Because it would include adding a column for it to the "user" table, mostly.