Re: Deprecating uniqid()

Rowan Tommins <rowan.collins@gmail.com> schrieb am Mo., 4. Mai 2020, 10:59: > On Mon, 4 May 2020 at 06:27, Andreas Heigl <andreas@heigl.org> wrote: > > > > > As replacement I could think of showing people the way to UUIDs. > > > > > Although the name sounds similar, I don't think UUID would be a good > replacement for uniqid(). In my experience, it's used for things like > generating ID attributes for HTML elements, or suffixes for table names, or > even file names; applications that really just need a few alphanumeric > characters that are different each time. > Seems like UUIDs would be a good fit for all of these. > > > As the function itself was never intended for cryptographically secure > > values I would not see random_* functions or the like as a replacement. > > > > > Firstly, while everyone *should* understand the phrase "cryptographically > secure", I don't think most users do. Despite the warning in the manual, I > would put money on people using uniqid() for things that really should use > "strong" randomness. > > Secondly, is there actually a *disadvantage* to using cryptographically > secure randomness when you don't need it? Speed? There's no advice in the > manual for random_int or random_bytes saying *not* to use them, and their > names seem deliberately chosen to imply they are the go-to functions for > randomness. > > The only downside I can see suggesting something like random_string(13, > '0-9a-f') as a direct replacement for uniqid() is that without a time input > it might happen to generate the same string twice in a request. On the > other hand, uniqid actually disclaims any guarantee of uniqueness anyway. > UUIDs have enough length to make collisions practically irrelevant, so again, they seem to be the best replacement. Best, Niklas Regards, > -- > Rowan Tommins > [IMSoP] >