Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72681
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.220.180 cause and error)
References: <CAGa2bXbNU-8HbbRrT5v33NWJPuQKSqxQa7HYDnKdrX07qfndBw@mail.gmail.com>
In-Reply-To: <CAGa2bXbNU-8HbbRrT5v33NWJPuQKSqxQa7HYDnKdrX07qfndBw@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQD49ZA6JgY/ePEgFR0D9Bs6n2u1g5xnUJQQ
Date: Tue, 18 Feb 2014 13:46:05 +0200
Message-ID: <2cb7cac279b9740f6ae011da15088ac9@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: zeev@zend.com (Zeev Suraski)

Yasuo,

This was previously discussed but I have to agree with Andrey (and maybe
even go beyond what he said) - the hash_bits change doesn't belong in this
RFC.  First, it has no security implications and it's not entirely clear
from the RFC.  Second, I don't feel that the implications of that change are
clear, beyond some mention that "this could not be an issue for almost all
apps", which personally I don't think is accurate - but either way, we need
some better analysis here.

From my point of view I don't think a few extra characters per session going
over the wire are worth the potential obscure BC break changing the default
here will cause with certain session backends and/or apps, and we shouldn't
include this change in this RFC.  If we want to compact the session id's,
proposing a change for this default can be done in a separate RFC that
discusses the pros and cons of doing it, independent of security.

Another thing that I think this RFC is missing is some clearer explanation
on what kind of apps *don't* work with the proposed changes (most notably
use_strict_mode=on and cookie_httponly).  Even though my gut is that these
two proposed changes are good - the RFC should include explanations of the
code patterns and/or types of apps and/or modules that will be affected by
this;  "Most apps should not be affected" isn't enough in an RFC IMHO.

Last - the voting period should be at least a week, right now it's 5 (or
maybe 6, depending on your POV) days.

Thanks!

Zeev

> -----Original Message-----
> From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
> Ohgaki
> Sent: Monday, February 17, 2014 6:27 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by
> Default
>
> Hi all,
>
> This RFC changes default session settings and introduces a new setting
> that
> disables possible timing attack against session ID. All of them help to
> improve
> general session ID security except hash_bits_per_character change.
>
> NIST discourages use of SHA-1 years ago. It proposes to use
> SHA-256 as the default hash function for session. To reduce size of
> session ID
> string, hash_bits_per_character=6 is proposed.
>
> https://wiki.php.net/rfc/secure-session-options-by-default
>
> Thank you for voting!
>
> P.S. Although, the change is trivial, if anyone would like to see patch
> for this,
> I'll prepare one ASAP.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net