2013/8/22 Leigh <lei...@gmail.com> > > On 22 August 2013 13:39, Sebastian Krebs <krebs....@gmail.com> 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
