Stanislav Malyshev wrote: >>> You really want a separate and distinct signed authentication cookie >>> that has nothing to do with the session. The stored session should >>> indicate which logged in user the session belongs to, but it should >>> never ever be used as the sole authentication cookie. That's what I >>> meant by a separate authentication layer. > > Could you explain why? If you can steal session cookie, you definitely > could steal any other cookie too. So stealing-wise, nothing is gained by > using separate cookie. Signing would help you to know the cookie is from > you, but I don't see how it's going to help you to know the cookie > belongs to whoever is attempting to use it. Could you elaborate?
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 completely. This also allows you to have different timeouts on the two. 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. 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. But yes, there isn't any standard approach to prevent cookie theft. It is up to the application to come up with a set of checks and restrictions that best meet the specific needs of that app. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
