2016-09-09 13:37 GMT+03:00 Niklas Keller <m...@kelunik.com>:
> 2016-09-09 10:36 GMT+02:00 Arvids Godjuks <arvids.godj...@gmail.com>:
>
>> 2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki <yohg...@ohgaki.net>:
>>
>>> On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller <m...@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
>>> yohg...@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.
>
I just don't need true random here, just some form of replacing an integer
ID with a value, that cannot be changed just by "+1"
>
>
>> 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.
>
The way the system works and that this is a semi-closed tool for business
purposes, the only real thing why we need these ID's is to track people.
Before this plain numeric ID's from the DB records were used. With the
rewrite the client asked to make ID's so you can't just do a +1 and see
something different. No one will ever want to try and break the uniqid algo
just to get the other page (probably the same text). I also use the
extended version of the uniqid.
>
>
>> 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?
>
Because it's a CSV import and I need to assign every record an ID at that
moment. Those ID's are then exported by admins to a 3rd party system.
>
>
>> 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. :-)
>
microtime and time are easier to guess. And time() is not an option,
because I will get 600 equal ID's then. Microtime is an option, but then
you get number only string and it looks awfully sequential :) Hence the
uniqid usage, that is basically time + microtime if I understand from the
manual, but it generates a bit more random result and I'm sure I get a
unique value on every call. Improving it so it does not look awfully
sequential would suffice for the use cases it is needed. In my case this
was a clearly conscious choice with full understanding how it works.
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
>
Hm, without "true" you get 13 chars, with "true" - 20+.
Arvids.
