Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29889
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <465C850D.9070807@lerdorf.com>
Date: Tue, 29 May 2007 12:54:53 -0700
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC:  internals@lists.php.net
References: <465C5D1D.7040206@gmail.com>  <465C6002.5080209@lerdorf.com>	 <1180462052.6874.204.camel@blobule>  <465C6D83.5000000@lerdorf.com> <1180463687.6874.210.camel@blobule> <465C7C99.4000707@lerdorf.com> <465C7E2C.4030601@gmail.com> <465C7F1E.3010605@zend.com>
In-Reply-To: <465C7F1E.3010605@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Session security
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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