Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL0xaBE-HzFz+rbzBJ_bEM1fuCKjcQ1K5yAokQra+CFMP_8x3w@mail.gmail.com>
References: <CAGa2bXaM8q0mwhkz+XL6jbBaVLHDZ_-Jfj0aOPUq+te=fV=wow@mail.gmail.com>
 <CANUQDCgcmLozTs4xcTTXfqd_UZC9oEKubmr_iZfYLwBcg3sxfQ@mail.gmail.com>
 <CAGa2bXb-ZD9ea+o4xqqsFtQJw7iM0Pzq1XTgof_2UPSTaY2PSg@mail.gmail.com> <CAL0xaBE-HzFz+rbzBJ_bEM1fuCKjcQ1K5yAokQra+CFMP_8x3w@mail.gmail.com>
Date: Fri, 9 Sep 2016 12:37:06 +0200
Message-ID: <CANUQDCgFzzCNCihP7DnsZRv8k7WkOT7htB_tKpoSp1wqpizmCQ@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013c646a5defe7053c10ba59
Subject: Re: [PHP-DEV] [RFC] Make uniqid() more unique
From: me@kelunik.com (Niklas Keller)

--089e013c646a5defe7053c10ba59
Content-Type: text/plain; charset=UTF-8

2016-09-09 10:36 GMT+02:00 Arvids Godjuks <arvids.godjuks@gmail.com>:

> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:
>
>> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller <me@kelunik.com> wrote:
>> > I think it's better to leave it as is and deprecate and discourage its
>> use.
>> > There's already a big warning there. Dunno whether there are really
>> valid
>> > use cases for it.
>>
>> uniqid() is handy, when developer would like to sort something by
>> "time" prefix/postfix in strings. For example, prefixed/postfixed
>> session ID by "time".
>>
>> So E_DEPRECATE might be too much.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>
> It's also useful in other cases, where using a full blown true random
> source is just overkill.
>

Most people think getting true random is a overkill and implement things
non-secure.


> For example, my recent usage was to use the result of uniqid('', true) as
> a few parameters in URL's instead of plain numeric ID. Client just wanted
> to users can't do a +1 and see someone else's result page that might have a
> different text or a different campaign even.
>

That's exactly where uniqid SHOULD NOT be used. It's predictable. Anyone
can easily guess these URLs. If you want to prevent that, you should use
non-predictable secure random, also called cryptographically secure random:
CSRPNG. See random_bytes and random_int.


> And I do need to generate those id's in bursts - 200 to 600 id's in a
> single action, I would imagine generating 600 random strings of ~20 char
> length can be hard on the source of the randomness, may even deplete it.
> And I expect the numbers to grow.
>

Could you outline why you need 200 - 600 IDs in a single action?


> So, deprecating it I think is really an overreaction. It's a handy tool.
> It can be used to generate filenames too, and a lot of other stuff.
>

Sure, but for that you can as well just use `microtime` or `time`. As
shown, it's easily misused, you're the perfect example. :-)


> My thoughts are - improve it. Yes, the standard uniqid() is a bit too
> short, I have never used it without the second "true" parameter and that
> dot in the middle of the string is annoying - I had to strip it out every
> use case I had.
>

`true` gives you exactly one character of more, pretty low entropy.

Regards, Niklas

--089e013c646a5defe7053c10ba59--