The session store is just a session store. It is not a login/authentication mechanism and thus doesn't have any of the protections you might want to add to that. Therefore a separate authentication cookie is needed that can separate the two concepts
I don't see how it's "therefore". Yes, session is just a storage. But how you derive from it that authentication information can not be stored in this storage and how the separate cookie is helping you in any way make it more secure?
completely. This also allows you to have different timeouts on the two.
That's a very specific case which doesn't really concern security but site policies. You could also expire values inside session, there are numerous wrappers doing it AFAIK, and even if you don't use such wrapper there's nothing hard in storing timestamp inside the session and expiring auth once the timestamp goes old.
For example, many sites let you stay logged in for weeks, but for any critical operation they have a much shorter timeout so they ask you to re-enter your credentials in order to perform that critical action.
That doesn't mean it should be implemented using separate cookie.
Also, any pages that have some sort of user action, typically a form, will have a crumb in it which is a small signed bit of data which is usually in a hidden field. This helps prevent cross site request forgeries by making each form specific to the logged in user.
That's nice but again is not related to cookies or sessions. This can be done without having separate auth cookie.
-- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
