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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
