Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72786
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZy=c2a6d+0XuQ2Ypteb7UeA1Ue0gfC2SejKN4m_YpP_eQ@mail.gmail.com>
References: <CAPhkiZxqmUVR3MhdMUBUuKxxkXndoTdoffbfuQ0oGc5JMvQ8dg@mail.gmail.com>
 <CAGa2bXbBnPQHqBUxe=S3HZtvQHQLdomEM4CEF3F+O0mf4oaktA@mail.gmail.com>
 <CAPhkiZx2sFqDmvdAsxOqqcrN6P09HW7MzFOA0cZbZ_2ruN4izw@mail.gmail.com>
 <CAGa2bXZbiTk_a=aJJY4iUPPaNQbv0yhyU2t6dXv2hAo0atiTdA@mail.gmail.com>
 <5302ABF6.60407@sugarcrm.com> <CAGa2bXbeGGFHJe8t7=9yDpuODWRq9+eVSeQ339j=1gzd4x9wGA@mail.gmail.com>
 <CAPhkiZx_sff8AcucRpHxb=f2w2DxKHt7SrOjQ1oTomrSa0oo-Q@mail.gmail.com>
 <CAGa2bXZVNaYFMR13m8WBv+-S2Yojv5Smg4dxqgQoVmCy3PXoOg@mail.gmail.com> <CAPhkiZy=c2a6d+0XuQ2Ypteb7UeA1Ue0gfC2SejKN4m_YpP_eQ@mail.gmail.com>
Date: Mon, 24 Feb 2014 18:31:37 +0900
Message-ID: <CAGa2bXZeA2G3APC8YeRSm=CWOepuVFBm=+oEc=zdc=XQ-bu=Nw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115ff34cff04604f323a599
Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0115ff34cff04604f323a599
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Fri, Feb 21, 2014 at 8:25 PM, Andrey Andreev <narf@devilix.net> wrote:

> On Thu, Feb 20, 2014 at 11:17 PM, Yasuo Ohgak
> Nobody has to guess the id length, as my quote below says: an attacker
> experienced enough to do timing attacks will always send a string with
> the full length.
> They do not have to know any secret, nor would they care if one
> exists. Your "id length" check will only "protect" you from a 13-year
> old using some brute-force script that they just found.
>

If underlying storage does liner search, you are right.
I was thinking this for mm handler, but it's useless if there is liner
search :(
Instead of having this, we should advise users to use good hash index.

>> >3 reasons.
> >> > - Hash used by session may fallback to SHA-1 from SHA-256
> >>
> >> What?! Why would that happen?
> >
> >
> > ext/hash could be DL module. There is #if for this case.
>
> This is a more serious flaw than the one you're trying to protect
> against. I'd suggest one of the following:
>
>  - Force ext/hash to be dynamically loaded when session wants to use it.
>  - Not give the ability to disable the extension at all.
>  - Emit E_WARNING when a user tries to use an unavailable algorithm.
>
> Actually, the last one should be done anyway, IMO.
>

OK. Third one seems the one to me, too.

 - hash_bits_per_character will be removed from the RFC.
 - Possible issue with ID length change will be documented.
 - "id_length" will be removed. User should use hash index search.
 - Raise error when hash function is not available.

Raising error seems not good...
If hash extension is available always, it might be easier for other module,
too.
Do not allow DL/disabling hash extension, perhaps?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0115ff34cff04604f323a599--