Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109986
MIME-Version: 1.0
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk>
 <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com> <3a2924d2-31b9-fee5-5548-49c889eca2f4@heigl.org>
In-Reply-To: <3a2924d2-31b9-fee5-5548-49c889eca2f4@heigl.org>
Date: Mon, 4 May 2020 09:59:11 +0100
Message-ID: <CALKiJKoXfW2usFmHS2ev2ihe6i=SV5JQaMgQmHCi5-rqeEdOWw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003f45b205a4cebf09"
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000003f45b205a4cebf09
Content-Type: text/plain; charset="UTF-8"

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.



> 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]

--0000000000003f45b205a4cebf09--