Hi all,
I've updated session security manual page a lot.
http://php.net/manual/en/session.security.php
Some of us do not realize importance of non adoptive session
management and timestamp management. e.g.
https://wiki.php.net/rfc/precise_session_management
https://wiki.php.net/rfc/session-use-st
Christian Schneider wrote:
Stut wrote:
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.
You want more info to be checked? Simply
On Tue, May 29, 2007 12:04 pm, Stut wrote:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general list.
>
> Why does the PHP session extension not use something like the user
> agent
> to validate that a session ID has not been hijacked? Or is this
> som
Stut wrote:
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.
You want more info to be checked? Simply add a variable containing
u
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, sessi
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
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 need
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.
As far as I understand, no, you can't, unless you have s
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 sepa
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.
Could you give an example of such checks?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] htt
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 conce
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 do
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
On 29 May 2007, at 7:16 PM, Rasmus Lerdorf wrote:
Stut wrote:
Hi all,
Just wanted to get your opinion on a discussion currently going on on
the general list.
Why does the PHP session extension not use something like the user
agent
to validate that a session ID has not been hijacked? Or is
The basic question is... is there any way to validate that a session ID
coming from the client is coming from the same client?
I'm afraid since there's no way (well, except for described below :) to
uniquely and securely identify the clients I don't see how you could do
that. You could use cli
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 auth
Rasmus Lerdorf 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
m
Robert Cummings wrote:
> On Tue, 2007-05-29 at 11:14 -0700, Rasmus Lerdorf wrote:
>> Robert Cummings wrote:
>>> On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
Stut wrote:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general
On Tue, 2007-05-29 at 11:14 -0700, Rasmus Lerdorf wrote:
> Robert Cummings wrote:
> > On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
> >> Stut wrote:
> >>> Hi all,
> >>>
> >>> Just wanted to get your opinion on a discussion currently going on on
> >>> the general list.
> >>>
> >>> Why doe
Robert Cummings wrote:
> On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
>> Stut wrote:
>>> Hi all,
>>>
>>> Just wanted to get your opinion on a discussion currently going on on
>>> the general list.
>>>
>>> Why does the PHP session extension not use something like the user agent
>>> to va
On Tue, 2007-05-29 at 10:16 -0700, Rasmus Lerdorf wrote:
> Stut wrote:
> > Hi all,
> >
> > Just wanted to get your opinion on a discussion currently going on on
> > the general list.
> >
> > Why does the PHP session extension not use something like the user agent
> > to validate that a session ID
Stut 写道:
Hi all,
Just wanted to get your opinion on a discussion currently going on on
the general list.
Why does the PHP session extension not use something like the user
agent to validate that a session ID has not been hijacked? Or is this
something that just hasn't been implemented yet?
Stut wrote:
> Hi all,
>
> Just wanted to get your opinion on a discussion currently going on on
> the general list.
>
> Why does the PHP session extension not use something like the user agent
> to validate that a session ID has not been hijacked? Or is this
> something that just hasn't been impl
On 29.05.2007 21:04, Stut wrote:
Hi all,
Just wanted to get your opinion on a discussion currently going on on
the general list.
Why does the PHP session extension not use something like the user agent
to validate that a session ID has not been hijacked? Or is this
something that just hasn'
Hi all,
Just wanted to get your opinion on a discussion currently going on on
the general list.
Why does the PHP session extension not use something like the user agent
to validate that a session ID has not been hijacked? Or is this
something that just hasn't been implemented yet?
-Stut
-
25 matches
Mail list logo
