Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Deprecation of uniqid()

Posted by Niklas Keller 
Niklas Keller
[PHP-DEV] [RFC] Deprecation of uniqid()
May 10, 2018 04:40PM
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
Arvids Godjuks
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 11:10AM
2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:

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

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 12:40PM
On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>
>> 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
Arvids Godjuks
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 01:00PM
2018-05-11 12:36 GMT+02:00 Alice Wonder <[email protected]>:

> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>
>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>
>> 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"

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 02:20PM
On 05/11/2018 03:50 AM, Arvids Godjuks wrote:
> 2018-05-11 12:36 GMT+02:00 Alice Wonder <[email protected]>:
>
>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>>
>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>>
>>> 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;
}

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 02:40PM
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 <[email protected]>:
>>
>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>>>
>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>>>
>>>> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 02:50PM
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 <[email protected]>:
>>>
>>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>>>>
>>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>>>>
>>>>> 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.
>

My point is that since it is trivial to create a function that is
compatible with the php function for backwards compatibility, the
problematic function in php itself doesn't need to exist.

For an actual unique id, code should be updated to generate an actual
nonce (either with pRNG every call or first time and increment if
predictable is okay) rather than use a function that clearly fails to
always produce something unique. So the function should go.

If I had a vote I would vote for the RFC and deprecate it.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 05:30PM
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 <[email protected]>:
>>>
>>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>>>>
>>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>>>>
>>>>> 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
Arvids Godjuks
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 11, 2018 11:10PM
2018-05-11 17:19 GMT+02:00 Alice Wonder <[email protected]>:

> 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 <[email protected]>:
>>>>
>>>> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>>>>>
>>>>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <[email protected]>:
>>>>>>
>>>>>> 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
>
>

Thank you for all the advice Alice :)
--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
Yasuo Ohgaki
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 13, 2018 12:50AM
On Fri, May 11, 2018 at 9:34 PM, Alice Wonder <[email protected]> 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>

uniqid() is one of the most abused function in PHP.
I don't have strong opinion against uniqid() deprecation, though.

Regards,

--
Yasuo Ohgaki
Alice Wonder
Re: [PHP-DEV] [RFC] Deprecation of uniqid()
May 13, 2018 02:10AM
On 05/12/2018 03:46 PM, Yasuo Ohgaki wrote:
> On Fri, May 11, 2018 at 9:34 PM, Alice Wonder <[email protected]
> <mailto:[email protected]>> 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>

+ random though is expensive if you have to create many at a time, using
an increment when called multiple times on same page requests results in
pattern but is less expensive.

So if predictable is okay that's better IMHO and often predictable (with
a pattern) is okay.

random based on time isn't necessary.

<time part> + <nonce>

should be sufficient.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login