is this safe to do?

[Anon]

Is this kind of authentication safe.
If the authentication was succesful the script will set a cookie where is a unique id and create a session where is the same id.

Everytime when user loads a page script will check if the id in the cookie is same than in session. If not user must login.

When the user log out the cookie and the sesson will be destroyd. There won\'t be a expire time in cookie, so it will be destroyd when the browser is closed.

[Anon]

It depends on what you want to be safe against.

If you are just making sure that the user did logon, then a value in the session data is enough, you don't even have to set a cookie.

If you want to protect against session hijacking, you'll have to do more, like sending cookies with randomly generated data. Don't use the session ID for this, because that is the first thing a hacker looks for.

Have a look around the forum and the columns for more info about "protecting" your site.

[Anon]

I don't think there is any value to adding another cookie to the session-handling mechanism. Here's why.

PHP session IDs are effectively random and unpredictable, so it's highly unlikely that a cracker is going to gain access to an active session by trying to guess or predict a key value.

Sessions work like a ski locker. You give the guy behind the counter your skis and he gives you a little blue numbered token. You go to the lodge and drink some hot chocolate. When you come back, you present your little blue token and get your skis back.

In order to have a session, an identifying token (session ID) has to be shipped back and forth over the wire. It's either shipped in the URL or it's shipped as a cookie. The token is what lets you resume a session where you left off.

If you add another cookie you are effectively requiring two tokens ... but you are still passing the tokens over a public channel.

If a cracker has access to the wire -- and can see everything that the user's Web browser can see -- then he/she/it can grab the token value (or keys) and easily counterfeit a request -- breaking in and stealing your snazzy new Rossignols.

You can make it harder in a practical sense by changing the session ID on each interaction, but you're still sending the token identifier across the wire where it could be grabbed by someone with physical access and a packet sniffer.

I don't think there's anything you can do to make the session significantly more secure without encrypting the entire communications channel through secure sockets (https).

If you are sending state secrets, financial data, or the true recipe for Mrs. Field's Chocolate Chip Cookies, then you probably ought to be running on a secure session.

But in other situations you should ask: How secure do I really have to be? In the ski-locker example, what's to stop a smart thief from showing up with a pocket full of fake tokens, watching with binoculars as you check in your skis, making note of the number, digging a matching token out of the stack, and showing up ten minutes later to hijack your equipment? And yet it doesn't happen very often. It's more trouble than it's worth.