[RFC] Make uniqid() more unique

> Hi all, > > On Fri, Sep 9, 2016 at 8:18 PM, Arvids Godjuks <arvids.godjuks@gmail.com> > wrote: > > > > Hm, without "true" you get 13 chars, with "true" - 20+. > > Sorry. It's > > $ php -r 'var_dump(uniqid(), uniqid("", true));' > string(13) "57d29c20c04c3" > string(23) "57d29c20c04c50.55225401" > > I misread sprintf format. > > Anyway, we may use extra 10 chars to make it more random if it should > keep compatibility.

> It seems uniqid() is popular for test scripts, so > it would be preferred keeping it.

> It does not harm any with test > script thanks to higher precision timers of current systems. >

> Some of us feel returning almost random value from uniqid() is > overkill.

> This is reasonable. I'll prepare patch that uses 10 chars > for 50 bits extra entropy from php_random_bytes() by default.

> Some of us feel returning almost random value from uniqid() is > overkill. This is reasonable.

> 2016-09-09 13:18 GMT+02:00 Arvids Godjuks <arvids.godjuks@gmail.com>: > >> >> >> 2016-09-09 13:37 GMT+03:00 Niklas Keller <me@kelunik.com>: >> >>> 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. >>> >> >> 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" >> > > If you know the time something was created you can still easily retrieve > it. It's not "+1" anymore, but only slightly better. > > >> >>> >>>> 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. >> > > uniqid() is just the current time. It's enough to be about unique in some > scenarios, but it's never unpredictable. If you want people not being able > to guess these URLs (by adding +1 or whatever), you need unpredictable > random. uniqid() doesn't fit here. uniqid("", true) doesn't fit either, as > it's just adding more time resolution and ONLY ONE SINGLE CHAR of random > data, which may be predictable, too, dunno what the generator here really > does. >

> > >> 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+. >> > > You get more chars, it's still predictable. > > Regards, Niklas >