On Mon, 4 May 2020 at 06:27, Andreas Heigl <andr...@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. > 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. Regards, -- Rowan Tommins [IMSoP]
