Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXafy794OxJDk0CNTaY5Te98O84HFAyuMJU7s819bX+tHw@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>
Date: Wed, 5 Feb 2014 22:00:52 +0200
Message-ID: <CAPhkiZwosTiKRudaNDhsoXHxkXjP=Qd_T4DCwhFmdJkVRmV=KA@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 again,

>> I am not referring to an old RFC, I'm saying this parameter is pointless.
>> What difference does it make at all? How does session_id() work with
>> and without it?
>
>
> Original proposal was
>
> session_id('SOME_USEFUL_PREFIX' . session_create_id());
>
> and allow to set ID. New one should be
>
>   bool session_id(string $new_id_or_prefix [, bool $use_prefix=FALSE]);
>
> (I thought I've updated the signature. It was old...)
> It supposed to used like
>
> session_id('PREFIX_', TRUE) // retunrs PREFIX_SECURE-SID
>
> New API would not allow insecure session ID when use_strict_mode=on while
> allowing user defined prefix for session ID.

You're not getting what I mean at all.

use_strict_mode should only validate cookie input, that's what it is meant for:

>> I'm not ignoring anything, I'm just saying this should be in a separate
>> RFC.
>>
>
> I have too many RFCs already...
> I would like to reduce number of RFCs.

Would you like it if people vote 'No' on this RFC because they like
the setting changes, but not the proposed session_id() parameter?
That's how I would vote if I could. :)

>> See my previous comment above.
>> You didn't chose a wrong name, you seem to have done a 2-in-1 RFC and
>> that's not the right approach IMO. At the very least - it's obviously
>> confusing and most of what you've said in this conversation isn't
>> described in the RFC at all.
>
>
> To me, it's the same objective that make session usage as secure as
> possible.
> I don't see reason to make 2 patches/RFC for making session module secure.
> Perhaps, better title would be
>
> "Make session options/API as secure as possible"
>
> 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.

It's not the same thing, not even the same category.

On the '_' character:

Any character passed to session_id() should be allowed, depending on
hash_bits_per_character and just for the underscore doesn't sound good
to me.

Cheers,
Andrey.