Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73263
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXaU8g6eApd+u4G5LZCkBhR=Qt3NmL0gyGxxQztZr4gxvA@mail.gmail.com>
References: <CAPhkiZz4bN8XQOtkeyXMArgdngHVjHY+0gf-Qnb9RY8xrxOZTg@mail.gmail.com>
	<CAGa2bXbF5ip_rzt+P3vc1ReEU-RoP5vGOnrTTDpTLeMGSLDrAg@mail.gmail.com>
	<CAPhkiZxAc_88dt469JuiAXrkRoDLfJ=Mtcasqr6vLcj_iDg1ig@mail.gmail.com>
	<CAGa2bXb5inv+aw8Y1502E+iHQautNggJaHj8RvqsAdo4MAgCDw@mail.gmail.com>
	<CAPhkiZxiXdHYo90cm=uZ+t2+DOuh9OWmkVNnnAGXC=TfznCvXw@mail.gmail.com>
	<CAGa2bXaU8g6eApd+u4G5LZCkBhR=Qt3NmL0gyGxxQztZr4gxvA@mail.gmail.com>
Date: Tue, 18 Mar 2014 12:23:41 +0200
Message-ID: <CAPhkiZxOV4GzjHOvaC7wTnnyhWuiG7w6VU0um19pAUnGDp=SxA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Solution for session_regenerate_id() issues
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Mar 18, 2014 at 1:07 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> I don't get it ... I thought you were proposing a solution in PHP
>> itself, not userland code. Am I missing something?
>
>
> I would like to fix this by PHP. i.e. session module.
> Therefore, I'm trying to change session module behavior.
>
> It's an example of proper/reliable session ID regeneration and session
> expiration
> handling in user land.

The userland solution works because it emulates a certain state of the
session between requests. I don't see how you'd do that in PHP itself
and even if you could, it might not be what everybody wants. I for one
would expect if I tell PHP to delete something, that thing to get
deleted immediately.

>> >> > Immediate deletion is worse than delayed deletion.
>> >>
>> >> I don't agree with this, but I guess we'll have to agree to disagree on
>> >> it.
>> >
>> >
>> > Letting user and/or attacker to know there is protection against session
>> > hijack
>> > is good for better security. It wouldn't prevent attack, but it
>> > mitigates
>> > risk.
>> > It's the same as having surveillance camera for security.
>>
>> Surveillance cameras may scare off a random criminal in real life, but
>> this is because it would film them and they'd be easily identified.
>> We're on the internet here and everybody can hide themselves, alerts
>> don't scare the kiddies.
>>
>>  - Letting the _application developer_ about an alleged attack is good.
>>  - Letting the user (as in an end user, just somebody using the site)
>> know about is irrelevant to security and bad from a usability point of
>> view, nobody likes to see errors in websites, to say the least.
>
>
> User is the only one that can identify which connection is legitimate or
> not.
> Therefore, app developers are advised to implement list/history of active
> sessions.

Advised !=  required.
User-accessible history != throwing errors in people's faces

>>  - Letting the attacker know about it is not just not good, it's
>> really bad. It further exposes details about the application to the
>> attacker; details that can be used to aid them in a more sophisticated
>> attack. They now know that there's something stopping them at some
>> point and so they learn how to avoid it.
>
>
> Consider which is good for attackers.
> Even dummy surveillance camera is good for security. It is good alarm
> attackers that they have been watched to prevent further attacks.

I already said this: we're on the internet, alarms are tools that can
aid attackers, you don't scare them off with it. Anyway ... I already
said that we'll have to agree to disagree on this, you obviously have
a completely different opinion.

>> > I'm proposing session manager does its task to make session management
>> > as secure as possible. I may agree with you if could explain why
>> > immediate
>> > deletion is better than delayed.
>>
>> It's simple - immediate deletion doesn't leave a time window for
>> attackers to exploit.
>
>
> As you and I point it out. Attackers may steal session ID as many times as
> they want.
> Immediate deletion would not provide surveillance, hence no mitigation. It
> also brings
> lost session issue for legitimate users.

It's up to application developers to decide if and how to implement
"surveilance", mitigation. I already explained previously how the
"lost session" issue is solved currently by many applications and I
see nothing wrong with it, you just can't make it a part of PHP
because any similar solution is unreliable (it assumes
JavaScript-triggered processes, PHP doesn't talk with JS) and
ultimately the app designer's choice (what if my application doesn't
use ajax?).

>> But speaking of sessions and security, I'll mail you privately about
>> something because I didn't see an option in the bug reporting form to
>> mark it as a private one.
>
>
> If you choose "security" bug type, it's hidden.
> Or if it's related to session module, you might want to send mail directly
> to me to discuss.

Great, I'll post it on bugs.php.net then and I'll mail you to sort out
how we can chat ... we've been going back and forth via mails for way
too long now.

Cheers,
Andrey.