Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29894
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error)
To: Stut <stuttle@gmail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Stanislav Malyshev <stas@zend.com>,  internals@lists.php.net
In-Reply-To: <465C88DC.8030704@gmail.com>
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>
	 <465C850D.9070807@lerdorf.com> <465C8641.5040507@zend.com>
	 <465C87E0.8040602@lerdorf.com>  <465C88DC.8030704@gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: InterJinn
Date: Tue, 29 May 2007 16:16:57 -0400
Message-ID: <1180469817.6874.214.camel@blobule>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] Session security
From: robert@interjinn.com (Robert Cummings)

On Tue, 2007-05-29 at 21:11 +0100, Stut wrote:
> Rasmus Lerdorf wrote:
> > Stanislav Malyshev wrote:
> >>> 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?
> > 
> > Because you don't have full control over the session cookie since it is
> > generated by PHP.  For an authentication cookie you want to layer other
> > application-specific checks on top of it.
> 
> I'm still unclear on how you validate that the authentication cookie 
> came from the same client machine as the one the application first sent 
> it to, which was the core of my question.
> 
> The answer seems to be that you can't do it reliably.

You don't have any cookie if the user has cookies disabled. So either
you use a policy that enforces the user to enable cookies or you fall
back on trans sid in which case, all bets are off since all you have is
the PHPSESSID stuck in the URL or form POST.

Cheers,
Rob.
-- 
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'