Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72194
Return-Path: <narf@devilix.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 86412 invoked from network); 4 Feb 2014 12:59:38 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 4 Feb 2014 12:59:38 -0000
Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.172 as permitted sender)
X-PHP-List-Original-Sender: narf@devilix.net
X-Host-Fingerprint: 209.85.160.172 mail-yk0-f172.google.com  
Received: from [209.85.160.172] ([209.85.160.172:41621] helo=mail-yk0-f172.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 5B/90-17725-934E0F25 for <internals@lists.php.net>; Tue, 04 Feb 2014 07:59:37 -0500
Received: by mail-yk0-f172.google.com with SMTP id 200so22182841ykr.3
        for <internals@lists.php.net>; Tue, 04 Feb 2014 04:59:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=devilix.net; s=google;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=LNFP7XdOFLZnOk/mn3mWYuvkrvfOUMnGq7TbFk9+zrk=;
        b=S4YT2G4W7Ejb4Qi8HyazKVdA+sNEQZI9sXakT2v2DTuwQHpytmGZAY0O/OhgbTEiPY
         gxujGisM6QbWzXA9qEKmwjRdv4U3vYJdecJra9rr2mj6NQaEMYbdNQZSTNSgavtVHDUg
         BzAklu8gZGtmx9063nRjf0QZmmBieWoT3xDpw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=LNFP7XdOFLZnOk/mn3mWYuvkrvfOUMnGq7TbFk9+zrk=;
        b=CWqV3PCfEdOfM8cJWGmmZOfxOo1AU8g8EAmLvJLNkj97F8pVj8RinqVPp/gYj7pJ8k
         BUm0W9rrx9Fv1LKj230zRmnFZ89kZpco4A2WmxmrcE36c7cxAiqwULyfn4sstvY0R8gx
         T6BdooXo5OEKGvhM6eWfA0v/ajjHcsNoC2/X/NeNDm+s3aHseucgI1zUoXtxjzuWIPk4
         /Rce07jNhy3jn6nqTUD2yOYML/lwX6QQHBYr3fe1Boo4WnRPyKe8gKY3u7Y6KpsQyBNt
         MpEOQKYLCRTff6cKxBf232x5t7pCTDgCPKLBhloGerlPB1z8ycrpS2oVo1PnCRROJP8y
         2Mgw==
X-Gm-Message-State: ALoCoQld8P+YXF8zgy168As32XYak2oMMKxhpr+w704bqhdqP4RM0n6r+/1DqRZRcNBLG/gmsltc
MIME-Version: 1.0
X-Received: by 10.236.170.3 with SMTP id o3mr204418yhl.143.1391518773219; Tue,
 04 Feb 2014 04:59:33 -0800 (PST)
Received: by 10.170.144.85 with HTTP; Tue, 4 Feb 2014 04:59:33 -0800 (PST)
In-Reply-To: <CAGa2bXYKtKX24p=XfTZdT_2E_543JDmZit6cKGMTLr-GuU7++A@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>
Date: Tue, 4 Feb 2014 14:59:33 +0200
Message-ID: <CAPhkiZyP3TOb8Y48GB58zYD6oSbpQ7k5Ngk6Yn2sd4YcJzRwPg@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)

>> >> 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?

>> >> 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.

>> 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.

Cheers,
Andrey.