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
