Well, on the outside, there really is no difference between a session and a cookie.
Namely, because in most instances, a session will be sent as a cookie.
Where the difference lays is in the fact that a session ID is the only thing sent via a cookie and that the session itself lives on the server in a nice little database set up for and by PHP... which of course is queried and updated automatically for you.
And the fact that you can have objects and arrays neatly stored within the session
and the session vars are all global.
A session is not (©2002 vincent) secure however. As the session ID may be used by anyone (ie h4><0r) who is able to intercept and capture that ID.
But... a session is far more secure than a cookie in the fact that we are not storing reusable information... atleast not past the session expiration, which is 2 hours for PHP (considering GC probability and lots of sessions), and the fact that the session cookie is never really set on the HD of the client since the session cookie comes with no timestamp.
Why use a PHP session?
The only reason is ease of use.
You could easily create your own session handler with a database and a no-lifetime cookie. But, unless you feel like a weekend of coding and debug (does it support proxies?) and all such fun stuff, I recommend using the PHP sessions.
If however, you have a big client with a good project budget and some serious security needs (the bigger the name the more the risk of hacks) then, I would look at writing some custom processes to handle the sessions. But if this is below a $10,000 site and/or with 100,000 hits or fewer a month, I'd say, PHP sessions straight up.
