Explode() assistance with cookies

I've been working from an article on php security using cookies. While I found the article to generally informative, it made the presumption that the individual reading the article was anything less than a knowledgeable programmer. I am a novice who is trying to learn to use good security practices from the start and need some assistance.

In the article it made reference to using cookies and imbedding information into the cookie and made a side remark about accessing that info through explode in order to continue authentication from page to page, but never delved into how this is accomplished.

Can someone please assist me in obtaining the info I need in order to continue my path?

I'm no guru on this, but I'd be pretty hesitant to store session variables in a cookie. FTD got into some big trouble with that this year. I'd be more inclined to use sessions. There are sessions tutorials here and at zend.com that are pretty handy, if I remember correctly. Sessions set session cookies that expire once the browser is closed and contain a session id. The session id saved in the cookie points back to a session id associated with data stored server side, which you can then access in PHP using the $_SESSION superglobal, no exploding necessary. Dig around the articles on this site and also head over to zend.com and check out their tutorials for some helpful info on how you might approach this issue.

Not too worried, since this is not going to be an advertised application. Though I will still take a look, but I'm not a fan of sessions. A friend also recommended them, but I like the idea of every page having to check for proper authorization and changing that auth ever 5 mins or so during the connection time. I appreciate your input however and will take your recommendation seriously as I am a novice.

Macinslaw

Think of a session as a cookie stored server-side. There's no saying you can't check every page for proper authorization. I'd argue that sessions are probably safer because the server, and not the client machine, holds the data (this is particularly safe, I would imagine, if you redefine the session handler so that session data are kept in a database rather than in writable /tmp space). Anything you can do to a cookie, you can do to a session, and in fact your implementation would be very similar for each -- rather than invoking the $_COOKIE superglobal, you'd invoke $_SESSION. Go down whatever path you'd like, but I'd think that as an admitted novice, you'd do well to consider going with the as-yet uncontradicted advice of a couple of programmers who've suggested one option as more secure than another. No skin off my nose either way, though. Good luck with it.

You bring a very good arguement to the table. And I would like to fully understand your method. Naturally as a novice, I am only interested in a few details:

1. Learning how to do this the right way.
2. Keeping my data safe and secure for my clients both now and in the future.
3. Learning something that can be done easily on all platforms.

If you, my senior, suggest sessions, then I am not one to argue. Please point me in the right direction so I may understand and complete my jedi training!

Thanks.

Macinslaw

I'd recommend googling for "PHP custom session handler." You're sure to find some results that'll show you how to handle your own sessions using a database. I've probably overstated my case a little. If your app passes no sensitive data along, using a cookie probably isn't the worst thing you could do. But you never want to store actual personally identifiable info or credit card numbers or unencrypted passwords, etc., in cookies. While sessions can be hijacked, if you expire them periodically and are careful about how you validate them, I think they beat cookies if only because they leave no usable information behind on the client machine. Since you said you wanted to learn to use good security practices, I thought I'd steer you away from the potentially bad path you were heading down. Of course, I'm sure there are plenty of people who would suggest that using sessions isn't a great option either. The general maxim tends to be that your security should be as strong as the data is important. That is, if nothing of any importance is going back and forth, a simple login scheme will suffice. But if you're passing banking info around, you'll want strong encryption and watertight authentication in place.

While the work I am pursuing is semi-sensitive, to their competitors, nothing of any real value will be passed. The only items I was pacing in the cookie was a login code, randomly generated, expired and recreated every couple of minutes, and a user id.

I appreciate your information and will make an attempt to learn about sessions and the hazards of both. I'm sure that each has their merit in certain situations. I guess I just mean to say, thanks for your assistance and for giving me another option.

Macinslaw