Cookie or Session?

[MikeD]

I'm about to go through all my code and update it to make it more efficient, and I wanted to know what would be the safer/easier option.

Currently the way I keep track of which warrior a player is using, I use a cookie, and in that cookie I use a 12 digit random number, so it would be extremely difficult to even try to use a warrior that wasn't yours. (I had other checks in place as well anyways).

My question is, would it be easier/more efficient/more secure to use a session with the warriors ID instead of a cookie?

[OoZI]

I personally use sessions just because I find them safer. I also find them easier to use, but I have used cookies before.

[Callan S.]

I think it'd be far safer and quite easy to just use sessions. I mean, your allowing data that can somehow reference resources that aren't the players be editable by the user (cookies are editable)?

I guess your running that 'is this warrior one the player owns' check every page view?

It'd be more efficient to read it from the cookie on log in, check the player owns it, then put it into a session variable so you don't have to check they own it anymore.

[Jackolantern]

Yeah, go with sessions. Cookies also have all kinds of shades of security options in most browsers. Many users are quite restrictive with them, and they can be set to be deleted quite often.

[Xaleph]

Yeah Sessions work better then cookies. Cookies can be quite easily disabled by the user or worse, modified by them. Either way, it`s a security issue you don`t need to risk because there are sessions. Now, don`t get me wrong, sessions isn`t the awnser to all the problems either because most browsers remember session information as well. So in order to have security in place, only provide a key in a session, really that`s all that should be in there. Now all you have to do is read the key, check your OWN software ( databases, scripts ) and match that key. if you do it with a database ( which i recommend ) you can store user sessions and bind them to a key, give the key to the users and use it to "open" the data in the database. Now you check and see when his last page visit was, if that was more then an hour ago or something, let them relogin and clear the database record. You can also store other data as well, like user ID, IP address et cetera, that way it`s easier to find the user who`s doing something.

Another option is a combination of a key + ip address as the final key, so the original key can be stolen but what are the odds of stealing that key + being on the same IP and all that within your given time limit? Pretty darn slim. Now you don`t share any real data with the outside, while still providing good security from within. It`s kind of like SSL except you dont run high encryption algorithms combined with the key of a browser, either way, the principle function remains.

[MikeD]

Thanks for the help, I will rework it into Sessions. I can't remember the reason why I left sessions in the first place, I think I got aggravated with something lol.