Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbwqn5NsTVLDsF01qTEQqX5bzzS=wTDQXtetkKwDY5a0g@mail.gmail.com>
References: <CAPhkiZxPZPatCKsCCih3YnOUmoUydk6MCvFjFB=AVvS-6bDYUQ@mail.gmail.com>
	<CAGa2bXb1ijUNA=RNFaTDnT7JjuVjWHp1aAiFxFXbCMwQqP-GjQ@mail.gmail.com>
	<CAPhkiZztkiKJQhU8ajajzUWOkbj_Hzon+8iCAVErRw=cMQGA8w@mail.gmail.com>
	<CAGa2bXbRjDZ6j-HuOTbv7OYO8=8nNxwhqKP7kDD=8e6Hnuqs+w@mail.gmail.com>
	<CAPhkiZwkdzzppBjsiFvFh7_mmWtbCKfo=OtYt-1RoB=4Kkcrzg@mail.gmail.com>
	<CAGa2bXYKtKX24p=XfTZdT_2E_543JDmZit6cKGMTLr-GuU7++A@mail.gmail.com>
	<CAPhkiZyP3TOb8Y48GB58zYD6oSbpQ7k5Ngk6Yn2sd4YcJzRwPg@mail.gmail.com>
	<CAGa2bXafy794OxJDk0CNTaY5Te98O84HFAyuMJU7s819bX+tHw@mail.gmail.com>
	<CAPhkiZwosTiKRudaNDhsoXHxkXjP=Qd_T4DCwhFmdJkVRmV=KA@mail.gmail.com>
	<CAGa2bXbwqn5NsTVLDsF01qTEQqX5bzzS=wTDQXtetkKwDY5a0g@mail.gmail.com>
Date: Thu, 3 Apr 2014 12:31:58 +0300
Message-ID: <CAPhkiZyhM9TB=+ASkk2v3U31o5YefCYZx8hnOaWNQEAwJt-q+w@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] [RFC] Secure Session Module Options by Default
From: narf@devilix.net (Andrey Andreev)

Hi,

>> > Regarding "_" addition to files save handler, it may not be RFC issue as
>> > it
>> > does not break anything at all. Just an simple addition of safe char
>> > that
>> > is needed for new safe prefixed session ID with hash bits=6. It may
>> > apply
>> > even prefixed session. I think there are many changes like this w/o RFC.
>> >
>> > I tried to write RFC to be minimum and sufficient. I should add more
>> > description
>> > if it is not. Or add link of this thread. I think it's preferred way.
>>
>>     Changing default settings in the proposed way makes ext/session
>> more secure by default.
>>
>>     Adding a new parameter to session_id() only gives users an easier
>> way to do complete a task that they otherwise *could* do the wrong
>> way.
>>
>> The first has real, straight-forward impact on security and doesn't
>> change existing functionality.
>> The second only *might* lead to some userland code being more secure
>> and it is questionable if that's the proper tool for the job. I for
>> one would like more tools that allow me to change a session's
>> behavior, but a prefix is not one of them.
>
>
> If you handle millions of sessions and would like to find specific
> active sessions with marginal overhead, prefixing is the way to
> go. Many users may not need it, but there are users who need.

Or, you could prefix (or add another field to check against) it in
storage, but leave the session ID itself untouched. That's not the
point though ... this just isn't a security feature and the RFC is
about improving security.

Can we move this forward now? I don't think there's anything more to discuss.
Btw, I'm still a proponent of changing hash_bits_per_character as
well, but IMO that may be done separately, without an RFC.

Cheers,
Andrey.