[RFC] Deprecation of uniqid()

> On 05/11/2018 05:34 AM, Alice Wonder wrote: > >> On 05/11/2018 05:10 AM, Alice Wonder wrote: >> >>> On 05/11/2018 03:50 AM, Arvids Godjuks wrote: >>> >>>> 2018-05-11 12:36 GMT+02:00 Alice Wonder <alice@librelamp.com>: >>>> >>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote: >>>>> >>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <me@kelunik.com>: >>>>>> >>>>>> Hey, >>>>>> >>>>>>> >>>>>>> I hereby propose to deprecate uniqid(). There have been attempts to >>>>>>> fix >>>>>>> it >>>>>>> ( >>>>>>> https://wiki.php.net/rfc/uniqid), but those were rejected during >>>>>>> discussion, because there's no possible fix without breaking BC. >>>>>>> Instead >>>>>>> of >>>>>>> a subtle BC break, this RFC favors the deprecation and moving >>>>>>> users to >>>>>>> other functions. >>>>>>> >>>>>>> It's to be discussed whether the function should be removed with >>>>>>> PHP 8.0 >>>>>>> or >>>>>>> just deprecated to avoid fully breaking things where it's not >>>>>>> strictly >>>>>>> necessary. A deprecation will probably avoid most new usages, >>>>>>> which is >>>>>>> the >>>>>>> main goal. >>>>>>> >>>>>>> RFC: https://wiki.php.net/rfc/deprecate-uniqid >>>>>>> >>>>>>> Kind Regards, >>>>>>> Niklas >>>>>>> >>>>>>> -- >>>>>>> PHP Internals - PHP Runtime Development Mailing List >>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>> >>>>>> as a userland user of this function I do disagree with it's outright >>>>>> removal. It has it's uses. >>>>>> What can be done with it is drop the $more_entropy flag and make it >>>>>> generate at least as long strings and use random_bytes under the >>>>>> hood for >>>>>> a >>>>>> better random. >>>>>> It can also adopt a length parameter so you can vary the random >>>>>> part as >>>>>> much as you need it. >>>>>> >>>>>> You don't always need a truly random token - I have a system that uses >>>>>> uniqid to generate tens of thousands tokens per request and it's >>>>>> actually >>>>>> a >>>>>> good thing they are time based at the start of it with a random >>>>>> part at >>>>>> the >>>>>> end (as I said the random part should be improved and get rid of that >>>>>> stupid dot when generating with $more_entropy = true). >>>>>> >>>>>> >>>>>> It seems to me that for your use case, you could just use the time() >>>>> function to get part of your unique id and then use libsodium to >>>>> generated >>>>> a nonce for the "random" part, using sodium's function for increment >>>>> the >>>>> nonce between each use. >>>>> >>>>> Predictable, sure, but your use case says they don't need to be a truly >>>>> random token - just unique (essentially a non-random nonce) but with >>>>> a time >>>>> component. >>>>> >>>>> >>>>> -- >>>>> PHP Internals - PHP Runtime Development Mailing List >>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> >>>>> >>>>> Hello Alice, >>>> >>>> Sure, there is lots I can do about that project, including what you have >>>> described. One thing though - client does not need it or want it or >>>> want's >>>> to pay for that work. That whole project is a poster child for a "side >>>> project on a bare minimum, but done by a competent developer instead >>>> of a >>>> student so it actually works in the long run" >>>> >>>> >>> Tell the client they can use this for free. >>> >>> function compat_uniqid(string $prefix='', bool $more_entropy = false) >>> { >>> static $nonce = null; >>> if(is_null($nonce)) { >>> $nonce = random_bytes(SODIUM_CRYPTO_SECRETBOX_NONCEBYTES); >>> } >>> $m = microtime(true); >>> $return = sprintf("%8x%05x",floor($m),($m-floor($m))*1000000); >>> if($more_entropy) { >>> sodium_increment($nonce); >>> $x = hexdec(substr(bin2hex($nonce),0,8)); >>> $x = str_pad($x, 12, "0", STR_PAD_LEFT); >>> $return = $return . substr($x, 0, 1) . '.' . substr($x, -8); >>> } >>> return $prefix . $return; >>> } >>> >>> >> slightly better if block >> >> if($more_entropy) { >> sodium_increment($nonce); >> $x = hexdec(substr(bin2hex($nonce),0,12)); >> $return = $return . substr($x, 2, 1) . '.' . substr($x, -8); >> } >> >> Obvious patterns in the "more entropy" but the output in only suppose to >> be unique, not random. >> >> > If you don't need the output to be exact same format, this avoids > collisions and is faster. > > function cryptoUniqid(string $prefix = '', bool $prng = false): string > { > static $nonce = null; > if($prng || is_null($nonce)) { > $nonce = random_bytes(16); > } else { > sodium_increment($nonce); > } > $m = microtime(true); > $return = sprintf("%8x%05x", floor($m), ($m-floor($m))*1000000); > $return = $return . '.' . base64_encode($nonce); > return $prefix . $return; > > } > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >

> On Fri, May 11, 2018 at 9:34 PM, Alice Wonder <alice@librelamp.com > <mailto:alice@librelamp.com>> wrote: > > slightly better if block > > if($more_entropy) { > sodium_increment($nonce); > $x = hexdec(substr(bin2hex($nonce),0,12)); > $return = $return . substr($x, 2, 1) . '.' . substr($x, -8); > } > > Obvious patterns in the "more entropy" but the output in only > suppose to be unique, not random. > > > The most important issue in current uniqid() is it could have duplicate > even with $more_entropy=true, since it has > > <time_part> + <random based on time> > > structure. > System time could be adjusted backwards by ntp, etc. > > However changing output by default as follows is enough for it. > > <time_part> + <random based on CSPRNG>