Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72072
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <52EF51FA.4000502@sugarcrm.com>
References: <CAGa2bXatpirSgsFhs1bdE72YCk3waPVsgr=M0NsRrwUZ3-5Uzg@mail.gmail.com>
 <52ED7AC8.6080703@sugarcrm.com> <CAGa2bXadBuhW73HP8y3ZDriStKQwOj8Ao+qe7BFFYOgY2C40_w@mail.gmail.com>
 <52EDF03C.5080201@sugarcrm.com> <CAGa2bXaviYguq9bAhHwAti0eOzdrUua9p_jVxZLZcLJ19CV1jQ@mail.gmail.com>
 <52EE1D2E.8060309@sugarcrm.com> <CAGa2bXaaGW5eQd_RgSQ4KQGUrkJmHHOgtwjxEYGVvps-wCYndw@mail.gmail.com>
 <52EF51FA.4000502@sugarcrm.com>
Date: Mon, 3 Feb 2014 19:35:26 +0900
Message-ID: <CAGa2bXZeC+DX7aGCZx+YerMndsx-7MxxCip6kjfg9aSNUotiyA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c34cb05171e704f17e17b4
Subject: Re: [PHP-DEV] [RFC] Secure Session Module Options by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c34cb05171e704f17e17b4
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Mon, Feb 3, 2014 at 5:23 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> > I see some users are generating unsafe session ID. Purpose of change is
> > not to generate insecure ID when user want some prefix in session ID.
>
> What's "insecure session ID" and how it is related to the matter we are
> discussing?


If there is not a easy way to create secure session ID (Currently, we
don't),
users may generate session ID by their own which may be insecure.


>  > Yes.
> > Currently, if 'foo' is not there already, session_id('foo') does not set
> > session ID, but creates new random session ID when use_strice_mode=on.
> >
> > string session_id(string $prefix_or_id [, bool $use_prefix=FALSE]);
> >
> > $use_prefix=TRUE will bypass use_strict_mode=on.
>
> I still don't understand what use_prefix has to do with secure session
> and why use_prefix would bypass strict mode. Something is missing here
> for me. Could you give some more detailed explanation of what you're
> trying to do here?
>

I see codes that set insecure session ID. use_strict_mode=on is supposed
to prevent it. However, there are users who want to have prefix as explained
before.

They would like to know session creation time, owner without actually
reading
session data for performance reasons.

I think this is valid use case of prefixed session ID.


> > As discussed in other thread, mcrypt_create_iv() is good one, but
> > it has some limitations. That's the reason why I think it would be
> > better to have function that generates secure random ID some how.
>
> We have two functions that generate random sequences - one in openssl
> and one in mcrypt. Why we need a third one?
>

This does not relates for this RFC anymore, since session_id(PREFIX, TRUE)
address creating secure session.


>
> > Anyway, it is time to compile openssl module by default. IMHO.
>
> Why we must control what the user compiles? The users that know what
> they're doing will compile it anyway, the users that don't will use
> distros which couldn't care less about our defaults and build all
> extensions separately anyway. I don't see which problem you're trying to
> fix here.
>

For instance, isn't it nice to have hardware AES available for
applications, is it?
Developers may assume users to load required extension, though.

 > It makes security a lot simpler/easier for both users and internal
> > developers.
>
> What exactly is hard now but becomes easier? Typing --with-openssl is
> not hard.


I see many use cases of random bytes and encryption.

For example, there is no 'standard' function generating secure random
bytes now. We could say use of uniqid() as a secure random source is
bad, but isn't it bad that we don't provide standard function for it?

Available optionally and available always is different. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c34cb05171e704f17e17b4--