Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72225
Return-Path: <yohgaki@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 81791 invoked from network); 5 Feb 2014 00:14:27 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 5 Feb 2014 00:14:27 -0000
Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.43 as permitted sender)
X-PHP-List-Original-Sender: yohgaki@gmail.com
X-Host-Fingerprint: 209.85.215.43 mail-la0-f43.google.com  
Received: from [209.85.215.43] ([209.85.215.43:56277] helo=mail-la0-f43.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id A0/30-12415-16281F25 for <internals@lists.php.net>; Tue, 04 Feb 2014 19:14:26 -0500
Received: by mail-la0-f43.google.com with SMTP id pv20so7098829lab.16
        for <internals@lists.php.net>; Tue, 04 Feb 2014 16:14:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:from:date:message-id
         :subject:to:cc:content-type;
        bh=aYKAEUJxI0tQtW819O3tDxPOh0FwWBTWtDCt8sMrVKs=;
        b=QmZkwIgG+mff3G2ZBHwygHls81zsmdL0ladSnqgF5Bf1dW5ZeG4mhq8dK97iKbW5VJ
         I8ljsjFervgCkaS5sXjBgoxju8xPHIdbeauvD2mrvM5JC6A+yut4y9wL/RWuOQyej1vY
         J4S6bvi3uw44JTDtUPvv02ShEsJ16DMlfb5DTpCZmCOBftS+9jlIPK59K3HEsKZ+GXbs
         wmmckAcT+MzQfhmYUnLnnfSULzyFtQosnNPW+Al+55sQdcFu8o5AC+t4z5bzY7vyETFW
         1n48o6hZa8fWbr5B8OWkvDoY+oTDS8FMTTKNMtCAJSckGxegLdxZRdrfJDg69cAPH9oN
         Xy4w==
X-Received: by 10.152.170.232 with SMTP id ap8mr71217lac.40.1391559262188;
 Tue, 04 Feb 2014 16:14:22 -0800 (PST)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
Received: by 10.112.199.37 with HTTP; Tue, 4 Feb 2014 16:13:42 -0800 (PST)
In-Reply-To: <CAPhkiZyP3TOb8Y48GB58zYD6oSbpQ7k5Ngk6Yn2sd4YcJzRwPg@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>
Date: Wed, 5 Feb 2014 09:13:42 +0900
X-Google-Sender-Auth: 26CuGIjwu7SP_oqrqfCel4reZKA
Message-ID: <CAGa2bXafy794OxJDk0CNTaY5Te98O84HFAyuMJU7s819bX+tHw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0117769181b7a304f19da397
Subject: Re: [PHP-DEV] [RFC] Secure Session Module Options by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e0117769181b7a304f19da397
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Tue, Feb 4, 2014 at 9:59 PM, Andrey Andreev <narf@devilix.net> wrote:

> >> >> I was just pointing out that 'use_strict_mode' shouldn't change the
> >> >> behavior of session_id().
> >> >> In other words, you don't need a "force" option, because passing a
> >> >> custom made ID by itself already tells it to force something.
> >> >
> >> > Change has been done already. It does not accept uninitialized ID when
> >> > use_strict_mode=On since 5.5.
> >>
> >> I know that. I'm saying it should work like you suggested without the
> >> need of another option.
> >>
> >> session_id(<user input>); // changes session ID to the user-supplied
> >> string, regardless of use_strict_mode
> >>
> >
> > You may be referring old RFC. Current RFC is
> >
> > Add optional $force_id parameter for session_id() to allow any id
> regardless
> > of this mode.
> >
> >   bool session_id(string $new_id [, bool $force_id=FALSE]);
> >
> > This was changed as Stas(?) suggested since I agree to him. It would be
> more
> > secure
> > than old one.
>
> 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.


>
> >> >> Don't know why you're talking about prefixes here ... nothing to do
> >> >> with security.
> >> >
> >> >
> >> > I see many codes that uses insecure session ID. The main reason why
> >> > they write such bad code is 'lack of secure ID generation feature'.
> >> >
> >> > It's security matter, IMHO.
> >>
> >> Why is that necessary at all? session_regenerate_id() not sufficient?
> >> Either way, this shouldn't be a part of this RFC.
> >>
> >> It's your RFC, but still - it's about changing default settings for
> >> improved security, not new features.
> >
> >
> > You are ignoring the fact that there is no  'default' function that is
> > securely generates random bytes/ID.
> >
> > There are code that requires prefix for much efficient session data
> > handling.
> > For example, user may want to know session creation time/owner/etc
> > *without reading* session data. With prefixed session ID, creation
> > time/owner/etc
> > is known just selecting session ID names. For databases like PostgreSQL
> > which
> > supports function index, searching specific session is done in msec order
> > even
> > when there are millions of session IDs.
>
> 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.


>  >> Because, as I said above - I thought this RFC was about changing
> >> default settings and nothing else.
> >> And again, an underscore *is not* a part of the hash, regardless of
> >> hash_bits_per_character.
> >>
> >> I personally don't care about the prefix. It's just that it's a
> >> completely new feature that has nothing to do with the default
> >> settings and it's just confusing that you mention it in the same
> >> context. :)
> >
> >
> > It's new for PHP, but there are codes do this and many of them are
> > insecure...
> > I would like to eliminate insecure code by introducing easy to use API
> also.
> >
> > I might have chosen wrong name for the RFC.
>
> 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.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e0117769181b7a304f19da397--