Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29897
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.174 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=fZ2TFoaC8DVCGn6A1TTc/9S0evb5uE/CfwRq4nXjBJEQIKlnbAfz54EK8fBlbWTLiTv760nmoRFmRnjuQX+EmA7JjZE/K5cePwYyaz209DYdfqX8rC7CoSeLqkmzNRqbSKbhQ78GmOfBRHkX6IPnfDBoPe056Xh0RHolqRGhabQ=
Message-ID: <465C8E23.1040803@gmail.com>
Date: Tue, 29 May 2007 21:33:39 +0100
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Robert Cummings <robert@interjinn.com>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 Stanislav Malyshev <stas@zend.com>,
  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>	 <465C850D.9070807@lerdorf.com> <465C8641.5040507@zend.com>	 <465C87E0.8040602@lerdorf.com>  <465C88DC.8030704@gmail.com> <1180469817.6874.214.camel@blobule>
In-Reply-To: <1180469817.6874.214.camel@blobule>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Session security
From: stuttle@gmail.com (Stut)

Robert Cummings wrote:
> 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.

Sorry, I should be using the term cookie when I mean session ID. It 
confuses people ;)

It doesn't matter where the session ID comes from, the basic point is 
that you have to trust it or implement some experience-degrading 
mechanism like client certificates, and even there there are few guarantees.

-Stut