Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69431
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAHMUw2EU_cSv_OL=PDm3mK3hURp=X=n0P1TbjrHZfjaPcKZJqA@mail.gmail.com>
References: <CAGa2bXbh6dOf41nZ0r-RuRtkCuuiA=r=SnxS+A1+GgqFXPGOWQ@mail.gmail.com>
 <CABBJUpdNr6McK6Q4qtztiYYG9CKZF7AeUdvo3YM+W0S87f8nDg@mail.gmail.com>
 <CAPwsocEwM_A3YraxZmJEXjBxaGgTZhfv711801bwtHLfJfNh+Q@mail.gmail.com>
 <CAHMUw2EQuT-y2Ho85QXhDdtysTWC=4FyY4nK9i-yR7qGqk6M=Q@mail.gmail.com>
 <CAPwsocGh-e1xAmvxgBF6St++9TBdW6uzRy8Xu4Jhb4p-N4vFvQ@mail.gmail.com>
 <CAGa2bXaH7B3vO=4Ap2hTfwUEp4Sw-PoK-omK6r=O71OUNksDxg@mail.gmail.com> <CAHMUw2EU_cSv_OL=PDm3mK3hURp=X=n0P1TbjrHZfjaPcKZJqA@mail.gmail.com>
Date: Tue, 1 Oct 2013 19:44:37 +0900
Message-ID: <CAGa2bXawswnLk+bEfZ_rG-r6+eWnYsmKpHSQWPgW0NzbXSYbjQ@mail.gmail.com>
To: Tjerk Meesters <tjerk.meesters@gmail.com>
Cc: Leigh <leight@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133eaca189e3f04e7aba683
Subject: Re: [PHP-DEV] Regenerating session ID automatically when IP address
 has changed
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1133eaca189e3f04e7aba683
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 30, 2013 at 4:51 PM, Tjerk Meesters <tjerk.meesters@gmail.com>wrote:

> On Sat, Sep 28, 2013 at 6:47 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi Leigh,
>>
>> On Fri, Sep 27, 2013 at 7:12 PM, Leigh <leight@gmail.com> wrote:
>>
>>> So on a successful session hijack (correct SID, new IP) the attacker
>>> gets a new SID and keeps the valid session while the legitimate user
>>> gets kicked out.
>>>
>>> Not seeing how that improves things at all.
>>>
>>
>> There are 2 improvements
>>
>> 1. Generally speaking, more frequent session ID regeneration is more
>> security.
>>
>
> This could make it more difficult for an attacker to take advantage, but
> then I would like to see other changes as well, for instance:
>
> a) Enable session.use_strict_mode by default.
> b) Enable session.use_only_cookies by default
> c) Enable session.cookie_httponly by default.
> d) Use a stronger session.hash_function with more
> session.hash_bits_per_character by default.
> e) Enable session.cookie_secure on secure connections (I know this is not
> going to be fool proof).
>
> There are probably more settings we could change to more security aware
> values.
>
>

I was thinking propose RFC some of these changes.



>  2. Detection/indication of attacks is good for security.
>>
>
> This is an interesting aspect; when an old session identifier is
> presented, from the end-user's perspective, either:
> a) They get redirected to the site's login page; the user gets redirected
> to the login page and unless they suspect their session was compromised (if
> that's indeed what happened), they will sign in again (the browser may have
> remembered the credentials, so it's a single click operation and they're
> back), or
>
> b) If the system uses a (naive) "remember me" feature, a new session gets
> created automatically and they don't notice a thing.
>
> From the server-side's perspective, the cookie value could simply not be
> found, assuming that the regeneration also deletes the previous session
> data; there's no discernible difference between an old session and a
> compromised session afaict. This would be a different story if the session
> engine would keep track of past values as well.
>
> Btw, what I'm also missing from this proposal is the ability to hash
> against other factors, i.e. user agent. ISP's may use a transparent HTTP(s)
> proxy, most companies use an NAT, so being able to detect user agent
> changes may improve detection further.
>
> The bottom line is: if the system can make it easier to detect intrusion,
> it should be in the system and it should be easy :)
>

I agree.
We can do many more things to make session more secure.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1133eaca189e3f04e7aba683--