Re: Request #65501 uniqid(): More entropy parameter should be true by default
2013/8/22 Leigh <[email protected]>
>
> On 22 August 2013 13:39, Sebastian Krebs <[email protected]> wrote:
>
>> Tbh I don't get the real problem with the _current_ behaviour. Who need
>> the
>> entropy, can set it as second parameter and I am not sure, if it is wise
>> to
>> use uniqid() for _security purposes_.
>>
>
> It's absolutely not wise to use it for anything security related, the
> purpose of the function is simply to provide a unique value within a
> system, not a random value, not an unpredictable value.
>
Thats what was my thought too, but the bugreport states
> Without more entropy, uniqid() may produce non unique id even if the
name states
> it. This could be security issue under certain cases.
> "more_entropy" in this case might as well be called "higher_resolution".
> As Nikita already pointed out, without this flag set a usleep is performed
> to force function calls to be at least 1 microsecond apart (since the id is
> microtime based). All more_entropy does is add some additional random on
> the end instead of the usleep so when uniqid is called multiple times
> during the same microsecond, the values are still (probably) unique.
>
Wait ... With "more" it is _faster_?! (Havent read Nikitas mail so closely
before...). Definitely something I should remember ^^ My trivial mind would
assume, that the longer output would take more effort.
>
> Making the function return a longer output by default is a BC break imo.
> As already pointed out constrained DB fields will not accept the new
> default, filenames generated using it will no longer conform to a set
> pattern, etc. etc.
>
Worth to mention: The longer output also contains a dot ".", which may lead
to worse things with filenames ;)
Regards,
Sebastian
--
github.com/KingCrunch
Thread (19 messages)