Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124440
Message-ID: <36c412df-7752-4554-af6b-d4696fbd2011@bastelstu.be>
Date: Mon, 15 Jul 2024 23:50:52 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>,
 internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
 <668B5728.40300@adviesenzo.nl> <61cbb650-17d7-4dbf-a73b-8265d6af2d4f@gmx.de>
Content-Language: en-US
In-Reply-To: <61cbb650-17d7-4dbf-a73b-8265d6af2d4f@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/15/24 15:56, Christoph M. Becker wrote:
> I do not, however, agree with the reasoning that a function (like
> uniqid()) is often used in a unsafe way (i.e. for purposes it has not
> been designed), and therefore should be deprecated/removed.  There are
> likely a couple of developers who are easily rolling their own
> implementation which can be way worse.  I've seen "encryption" code

That's effectively what's already being done, with complex, but 
meaningless, constructions such as `sha1(uniqid(microtime(true), 
true).rand())`. I probably did so myself in the past, back when I didn't 
know better and followed tutorials that also didn't know better.

I agree that it helps no one if the cure is worse than the disease.

That's why I strongly believe in misuse-resistant APIs: The secure 
choice should also be the default choice and also the easiest choice. 
The 'password_*' API is an great example for that. It has a few 
functions that do exactly what they say on the tine. You basically 
cannot use it incorrectly (except by not using it).

The old procedural API to use randomness is not such an example [1]. The 
`uniqid()` function is the most obvious choice to generate a unique 
string and when using it, the output also looks "random". But in reality 
it does not guarantee that the output is unique or unguessable - making 
the function name a lie.

It's almost always the wrong choice and I expect the type of developer 
that is able to use it safely to be able to write their own 
domain-specific formatter for the current time. All other users would be 
better suited by choosing something else, such as the 
`bin2hex(random_bytes(16))` construction that is supported since 7.0 and 
even longer with ParagonIE's polyfill [2]. Yes, it is not as terse as a 
call to `uniqid()`, but it is nicely explicit in what the output will 
look like and what the security properties are.

> which was basically a Caesar cipher, spiced with some obsure function
> calls to make it "even more safe".  And I've seen obscure HTML escaping
> code with an not so obvious back-door, that was once available as user
> note on php.net.
> 
> That doesn't mean that I'm against the uniqid() deprecation, especially
> if the deprecation message is clear on what to use instead.

I will make sure to write useful migration docs, helping users making an 
educated choice for an alternative. Unfortunately is no 
one-size-fits-all solution to the problem of generating an unique string.

Best regards
Tim Düsterhus

[1] This includes uniqid(), rand(), mt_rand(), lcg_value(). 
random_bytes() and random_int() are fine.
[2] https://github.com/paragonie/random_compat