[PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4

Mailing Lists php.internals
21

On Jul 25, 2024 at 5:35 PM, <Rowan Tommins [IMSoP]> wrote:
Rather than force people to use functions that we acknowledge are hard

to use, surely the logical thing is to make the "right" code *easy* to use?

Which means if we want people to use SHA-256, let's add a sha256()  
function to make it easy.

This is what password_hash() and password_verify() did right: the  
functionality was already there in crypt(), but it's hard to use, and  
harder to use correctly. Providing clearer functions, even though they  
do the same thing, helps new developers "fall into the pit of success".

Yes! 1000% THIS.

-Mike

The hash() function isn't quite as confusing as crypt(), but according  
to the manual, it currently supports 60 different algorithms, most of  
which I have never heard of. I'm aware that "sha256" is better than  
"sha1", but should I be aiming higher, and using "sha384", or maybe one  
of the four flavours of "sha3"? Then there's the fun-sounding  
"whirlpool", the faintly rude-sounding "snefru", and a bewildering  
fifteen flavours of "haval".

A new user being told "don't use sha1(), use hash() and pick from this  
list" is more likely to say "ah, there's sha1, jolly good" than spend an  
afternoon reading cryptography journals. There's no pit of success to  
fall into.

Regards,

--  
Rowan Tommins
[IMSoP]
22

On Jul 25, 2024 at 6:02 PM, <Nick Lockheart> wrote:
That’s a good point. What if there were crypto functions that worked

like password_hash() in that they had one generic function name, but
magically used the new/better "best practice" algorithms as time went
by without the need to update any calling code?

Maybe there should be three generic-named functions:

fast_hash() // not secure, makes UIDs quickly
secure_hash() // uses best practice one-way hash algo
secure_crypt() // uses best practice reversible encryption.

Then the developer signals their *intent* by choosing a function name,
and the algorithm magically works underneath (perhaps with the option
of an ini override to make those functions work in different
environments).

If those were added, I would bikeshed their names to make sure their intent was 100% clear:

insecure_hash() // not secure, makes UIDs quickly
secure_oneway_hash() // uses best practice one-way hash algo
secure_reversible_hash() // uses best practice reversible encryption.

-Mike

23

While I like the idea, this sounds like a huge nightmare in the waiting when data is stored somewhere and later compared. Example: * Let’s say these functions get introduced in PHP 8.5. * secure_hash() is used in an application running on PHP 8.5 to secure some data before storing it in a database. This data is used in comparisons - stored vs user provided. * Now in PHP 9.1, the hash algorithm is changed. * The production environment gets updated to PHP 9.1 and suddenly the application breaks as the data verification will no longer work as the new algo is used on the user provided data, but the database stored version of the same data was created with the old algo…

···

On 26-7-2024 0:00, Nick Lockheart wrote:

That's a good point. What if there were crypto functions that worked
like password_hash() in that they had one generic function name, but
magically used the new/better "best practice" algorithms as time went
by without the need to update any calling code?

Maybe there should be three generic-named functions:

fast_hash() // not secure, makes UIDs quickly
secure_hash() // uses best practice one-way hash algo
secure_crypt() // uses best practice reversible encryption.
24

On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer wrote:

On 26-7-2024 0:00, Nick Lockheart wrote:

>
> That's a good point. What if there were crypto functions that
> worked
> like password_hash() in that they had one generic function name,
> but
> magically used the new/better "best practice" algorithms as time
> went
> by without the need to update any calling code?
>
> Maybe there should be three generic-named functions:
>
> fast_hash() // not secure, makes UIDs quickly
> secure_hash() // uses best practice one-way hash algo
> secure_crypt() // uses best practice reversible encryption.

While I like the idea, this sounds like a huge nightmare in the
waiting when data is stored somewhere and later compared.

Example:
* Let's say these functions get introduced in PHP 8.5.
* `secure_hash()` is used in an application running on PHP 8.5 to
secure some data before storing it in a database. This data is used
in comparisons - stored vs user provided.
* Now in PHP 9.1, the hash algorithm is changed.
* The production environment gets updated to PHP 9.1 and suddenly
the application breaks as the data verification will no longer work
as the new algo is used on the user provided data, but the database
stored version of the same data was created with the old algo....

Doesn't password_hash() handle this automatically? The result of the
password_hash() function includes the hash and the algorithm used to
hash it. That way password_verify() magically works with the string
that came from password_hash().

25

On Thu, Jul 25, 2024 at 8:33 AM Tim Düsterhus <tim@bastelstu.be> wrote:

No, we are talking about end users who are following tutorials that were
written when PHP 4 was the most recent PHP version.

We are also talking about end users who look at existing code bases for
“inspiration”, see md5() used, notice that the output looks random and
use it, believing they know what they are doing, but in that process use
it in a way that is insecure.

Hi Tim,

How prevalent is this exactly? PHP 4 ended support in 2008. I think putting warning labels on these things in the docs is enough, but we can’t go around locking up every kitchen knife just because there are some idiots out there who read a book from the 50s about the war.

And like I said previously, this change isn’t what is going to determine if those people will write good, reliable, secure code. If their learning insticast can’t see past a blog tutorial from 20 years ago, not even to look up the function in the manual, they will not ever achieve that.

I’m positive that even existing projects written by experienced
developers would benefit from re-checking if their use of MD5 and SHA-1
is actually safe instead of assuming that this is the case, when the
specific functionality has been untouched for the last 10 years.

You can say this about pretty much every software project in existence, regarding anything. I just don’t think it’s up to PHP to mandate these checks. If you want to create a fund for developers to go review their code on the clock, fine, but don’t force it on them. Might as well deprecate everything each major version to force people to rewrite their projects to “current best practices”. If I wanted to do that, I’d just use the JS framework of the month.

Looking back at my own code, I’m seeing places where using SHA-1 is not
strictly insecure, but where a stronger hash function nevertheless would
have been more appropriate, if only to simplify code audits. I just used
sha1(), because it was temptingly convenient compared to hash(‘sha256’, …).

sha1 was the “proper” alternative to md5, until it wasn’t. md5 superceeded crc32, which btw, why isn’t that on the hit-list?

You’re using sha256? It’s soooo outdated, use sha512 and key it with hmac, you casual /s

SHA-1 is a deterministic algorithm, thus it is unable to generate a
random UID. Whatever this code is doing can most likely be more reliably
achieved in a different way.

ALL hashing functions are deterministic. That’s the whole point, and applies to sha256 just the same. You want to be able to hash the same content and get the same hash. Just the complexity and chance of collision changes. The reliability and security you are concerned with in this scenario really depends on what randomness you feed it.

Thanks,
Peter

26

On 25 July 2024 23:54:53 BST, Nick Lockheart <lists@ageofdream.com> wrote:

Doesn't password_hash() handle this automatically? The result of the
password_hash() function includes the hash and the algorithm used to
hash it. That way password_verify() magically works with the string
that came from password_hash().

For password hashing, you are always retrieving the hash for a specific user, and then making a yes/no decision about it. Indeed, it's an explicit aim that an attacker can't take a password and quickly scan a captured database for matching hashes.

For other uses of hashes, though, the opposite is true: you want to search for matching hashes. For instance, when you store a file in git, it calculates the SHA1 hash of its content to use as a lookup key. If that key already exists in the local database, it assumes the content is the same.

That also demonstrates another difference: hashes are often shared between applications, where they need to be using an agreed algorithm. If a package manager requires SHA1 hashes of each file, you can't just substitute SHA256 hashes without some other agreed changes.

Tempting though a "secure_hash" function is, I don't think it's practical for a lot of the places hashing is used.

Regards,
Rowan Tommins
[IMSoP]

27

On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman <sarkedev@gmail.com> wrote:

If their learning insticast

*instincts.

I should also clarify, I’m not against deprecations in general. However, the benefits should outweigh the costs. If something is getting unmaintainable, no longer supported, inherently insecure etc, those are all good reasons. password_hash as mentioned was a great addition, and should/did solve this very issue. Even someone reading a blog tutorial from 11 years ago would be able to see this used properly.

But md5/sha1 are not bad functions, they do exactly what they say on the box. Being able to do the exact same thing by spelling the function slightly differently isn’t even deprecating them, just deprecating an alias. They’re only bad if used in a bad way, and that to me is not enough of a reason.

Thanks,
Peter

28

On Friday, 26 July 2024 at 08:09, Peter Stalman <sarkedev@gmail.com> wrote:

On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman <sarkedev@gmail.com> wrote:

If their learning insticast

*instincts.

I should also clarify, I'm not against deprecations in general. However, the benefits should outweigh the costs. If something is getting unmaintainable, no longer supported, inherently insecure etc, those are all good reasons. `password_hash` as mentioned was a great addition, and should/did solve this very issue. Even someone reading a blog tutorial from 11 years ago would be able to see this used properly.

But md5/sha1 are not bad functions, they do *exactly* what they say on the box. Being able to do the exact same thing by spelling the function slightly differently isn't even deprecating them, just deprecating an alias. They're only *bad* if used in a *bad way*, and that to me is not enough of a reason.

Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1]
A warning on a documentation page is useless, as nobody is forced to read it.

Yet again the PHP community doesn't care about security of its users, current and future, and just prefers the convenience of needing to type less characters and not go back fix some code for better design.

I am not sure why I was expecting something else, but I guess I am just disappointed.
I suppose we are truly becoming Oracle.

Sincerely,
Gina P. Banyard

[1] x.com

29

Yet again the PHP community doesn't care about security of its users, current and future, and just prefers the convenience of needing to type less characters and not go back fix some code for better design.

Gina P. Banyard

If you describe it in such a dramatic fashion, then there is no reason to keep sha/md5 functionality in hash too?

One could come up also with a different statement - "the PHP community doesn't care about backwards compatibility (in favor of questionable deprecations/removals)" (which at some point even borders with some "Karma farming" [1])

[1] OpenSSF Warns of Reputation Farming Leveraging Closed GitHub Issues and PRs - Socket

rr

30

The only thing that removal of these functions would cause is a.) make people rant about php unnecessarily b.) 99.9% would counter the removal of these functions bys adding this kind of code in their bootstrap, maybe include a polyfill library via composer.

if (!function_exists(‚md5‘)) { function md5($data) { return hash(‚md5‘, $data); }}

···

On Friday, 26 July 2024 at 08:09, Peter Stalman <sarkedev@gmail.com> wrote:

On Thu, Jul 25, 2024 at 11:35 PM Peter Stalman <sarkedev@gmail.com> wrote:

If their learning insticast

*instincts.

I should also clarify, I’m not against deprecations in general. However, the benefits should outweigh the costs. If something is getting unmaintainable, no longer supported, inherently insecure etc, those are all good reasons. password_hash as mentioned was a great addition, and should/did solve this very issue. Even someone reading a blog tutorial from 11 years ago would be able to see this used properly.

But md5/sha1 are not bad functions, they do exactly what they say on the box. Being able to do the exact same thing by spelling the function slightly differently isn’t even deprecating them, just deprecating an alias. They’re only bad if used in a bad way, and that to me is not enough of a reason.

Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1]
A warning on a documentation page is useless, as nobody is forced to read it.

Yet again the PHP community doesn’t care about security of its users, current and future, and just prefers the convenience of needing to type less characters and not go back fix some code for better design.

I am not sure why I was expecting something else, but I guess I am just disappointed.
I suppose we are truly becoming Oracle.

Sincerely,

Gina P. Banyard

[1] https://x.com/valorin/status/1816593881791860963

31

On 26.07.2024 at 12:03, Gina P. Banyard wrote:

Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1]
A warning on a documentation page is useless, as nobody is forced to read it.

Right, but even a deprecation notice is likely to be ignored by those
(either use the shut-up operator, or use hash("md5), or maybe a polyfill
to support old PHP versions), so the deprecation wouldn't help in such
cases.

(I've recently seen a new release of a software which still uses
<https://www.openwall.com/phpass/&gt;\. Apparently, the notice to prefer
the password_*() API has been ignored or overlooked.)

On the other hand, I'm quite confident that a deprecation could be
useful for some developers, who would at least reconsider the use of
md5/sha1 hashes, but just have overlooked this; although some static
analysis should report respective issues. However, there is certainly
code without any static analysis, where at least this discussion appears
to be helpful, e.g. our php-sdk-binary-tools might reconsider their use
of md5() and md5(uniqid())[2].

Note that I'm not against these deprecations, but I'm also not strongly
in favor. I see valid arguments from both proponents and opponents.

[1] x.com

[2] <Issues · php/php-sdk-binary-tools · GitHub;

Cheers,
Christoph

32

Hi

On 7/26/24 08:35, Peter Stalman wrote:

How prevalent is this exactly? PHP 4 ended support in 2008. I think
putting warning labels on these things in the docs is enough, but we can't
go around locking up every kitchen knife just because there are some idiots
out there who read a book from the 50s about the war.

I just Googled "PHP tutorial" and found https://www.phptutorial.net/ as the second search result, which considers itself to be "the modern PHP tutorial".

I've clicked at the CSRF section (PHP CSRF) and what do I find:

> $_SESSION['token'] = md5(uniqid(mt_rand(), true));

*Exactly* the md5-uniqid construction that is called out as unsafe in the RFC and used in a security context.

Further down on the first page I find PHP - MySQL Login, which does not even hash the passwords that are stored within the database. At least it's using `mysqli_real_escape_string()`.

Then I have the German php-einfach.de, which on Die wichtigsten PHP Funktionen im Überblick – PHP lernen ("the most important PHP functions") lists md5() and sha1() as an important function, but does not mention hash() at all.

I'm sure I would find quite a few more, but I believe those already support the point I was trying to make.

And like I said previously, this change isn't what is going to determine if
those people will write good, reliable, secure code. If their learning
insticast can't see past a blog tutorial from 20 years ago, not even to
look up the function in the manual, they will not ever achieve that.

I think you are expecting a little too much from a beginner that is following "the modern PHP tutorial" if you expect them to critically question whether the tutorial is actually good or not. They are likely already struggling with syntax and explaining the difference between "if" and "while". You wouldn't believe how often I've heard the term "if-Schleife" (if loop) in German.

I'm positive that even existing projects written by experienced
developers would benefit from re-checking if their use of MD5 and SHA-1
is actually safe instead of assuming that this is the case, when the
specific functionality has been untouched for the last 10 years.

You can say this about pretty much every software project in existence,
regarding anything. I just don't think it's up to PHP to mandate these
checks. If you want to create a fund for developers to go review their
code on the clock, fine, but don't force it on them. Might as well

A deprecation is not forcing anything. It's an indicator that whatever you are doing might not be the best current practice. You are free to ignore it and in this specific case you are not even at the risk of removal, because the RFC does not propose the removal.

Looking back at my own code, I'm seeing places where using SHA-1 is not
strictly insecure, but where a stronger hash function nevertheless would
have been more appropriate, if only to simplify code audits. I just used
sha1(), because it was temptingly convenient compared to hash('sha256', …).

sha1 was the "proper" alternative to md5, until it wasn't. md5

Right, technology advances and security is a moving target. What is the point you are trying to make?

superceeded crc32, which btw, why isn't that on the hit-list?

CRC32 does not claim to be a cryptographically secure hash algorithm. Its use case is completely different.

You're using sha256? It's soooo outdated, use sha512 and key it with hmac,
you casual /s

I'm seeing the sarcasm indicator, but I'm compelled to point out that SHA-256 and SHA-512 are both SHA-2. If one is broken, it is likely that the other is as well.

SHA-1 is a deterministic algorithm, thus it is unable to generate a

random UID. Whatever this code is doing can most likely be more reliably
achieved in a different way.

ALL hashing functions are deterministic. That's the whole point, and

Yes, that's why I asked how they are using a hash function to get a random result.

applies to sha256 just the same. You want to be able to hash the same
content and get the same hash. Just the complexity and chance of
collision changes. The reliability and security you are concerned with in
this scenario really depends on what randomness you feed it.

My point was that if you already have randomness then you don't need to pair it with a hash function. You don't gain any randomness by passing it through a hash function. Just convert the randomness to a readable representation using bin2hex, base64_encode or by using Randomizer::getBytesFromString().

Best regards
Tim Düsterhus

33

On 26 July 2024 11:03:53 BST, "Gina P. Banyard" <internals@gpb.moe> wrote:

Yet again the PHP community doesn't care about security of its users, current and future, and just prefers the convenience of needing to type less characters and not go back fix some code for better design.

This is a gross misrepresentation of what people are saying. I am in favour of the *aim* of educating users to use better hashing functions, but I don't agree that the proposed deprecation is the right way to achieve that aim.

Maybe some people who already know SHA1 is outdated will be prompted to say "huh, I hadn't realised we used it there, let's add a backlog task to migrate to something else". But just as likely they'll do that during a security audit anyway.

The people you really want to reach, those who don't know much about it, will do a find-and-replace from "sha1(" to "hash('sha1', " and gain nothing.

The deprecation *might* make sense alongside introducing some new functions that we want people to discover instead, but on its own, I don't think the benefits outweigh the costs.

Regards,
Rowan Tommins
[IMSoP]

34

On Fri, Jul 26, 2024, at 13:58, Tim Düsterhus wrote:

Hi

On 7/26/24 08:35, Peter Stalman wrote:

How prevalent is this exactly? PHP 4 ended support in 2008. I think

putting warning labels on these things in the docs is enough, but we can’t

go around locking up every kitchen knife just because there are some idiots

out there who read a book from the 50s about the war.

I just Googled “PHP tutorial” and found https://www.phptutorial.net/ as

the second search result, which considers itself to be "the modern PHP

tutorial".

I’ve clicked at the CSRF section

(https://www.phptutorial.net/php-tutorial/php-csrf/) and what do I find:

$_SESSION[‘token’] = md5(uniqid(mt_rand(), true));

Exactly the md5-uniqid construction that is called out as unsafe in

the RFC and used in a security context.

In regards to hashing, this is likely fine; for now. There still isn’t an arbitrary pre-image attack on md5 (that I’m aware of). Can you create a random file with a matching hash? Yes, in a few seconds, on modern hardware. But you cannot yet make it have arbitrary contents in our lifetime. The NSA probably has something like this though, but if so, this isn’t widely known.

That being said, this is just randomly creating a random id without leaking it’s internal construction, no different than putting an md5 in a UUID-v8. The real issue here is the use of uniqid() and rand(), making it quite likely (at scale, at least) that a session id will overlap with another session id.

— Rob

35

HI

On 7/26/24 14:50, Rob Landers wrote:

$_SESSION['token'] = md5(uniqid(mt_rand(), true));

*Exactly* the md5-uniqid construction that is called out as unsafe in
the RFC and used in a security context.

In regards to hashing, this is likely fine; for now. There still isn't an arbitrary pre-image attack on md5 (that I'm aware of). Can you create a random file with a matching hash? Yes, in a few seconds, on modern hardware. But you cannot yet make it have arbitrary contents in our lifetime. The NSA probably has something like this though, but if so, this isn't widely known.

Neither collision-, nor pre-image resistance is relevant here. The attack vector is a brute force attack / an attacker guessing the token rather than the token's contents.

That being said, this is just randomly creating a random id without leaking it's internal construction, no different than putting an md5 in a UUID-v8. The real issue here is the use of uniqid() and rand(), making it quite likely (at scale, at least) that a session id will overlap with another session id.

The point is that it showcases a fundamental misunderstanding of what MD5 (or really any other hash algorithm) does for you. The application of the MD5 does not make the token more random or more unique or whatever positive adjective you would like to use. It would be equally strong (or rather weak) if the output of `uniqid(mt_rand(), true)` was used directly.

As per Kerckhoffs's principle, the security of the algorithm must not rely on the attacker not knowing how it's implemented. Given how prevalent constructions like the above are, an attacker could make an educated guess about how it looks like and match their own token against a precomputed table to find out if it matches.

Best regards
Tim Düsterhus

36

On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote:

I think you are expecting a little too much from a beginner that is
following "the modern PHP tutorial" if you expect them to critically
question whether the tutorial is actually good or not. They are likely
already struggling with syntax and explaining the difference between
"if" and "while". You wouldn't believe how often I've heard the term
"if-Schleife" (if loop) in German.

I think you are expecting a little too much from a beginner if you think they will see the message "md5() is deprecated", and research up to date advice on hashing algorithms, rather than asking ChatGPT how to make the code work, and replacing it with "hash('md5', ...)".

CRC32 does not claim to be a cryptographically secure hash algorithm.
Its use case is completely different.

As an inexperienced user looking at the PHP manual for hash() and hash_algos(), how would I know that? It's right there in the list, just after something called "adler32".

I'm seeing the sarcasm indicator, but I'm compelled to point out that
SHA-256 and SHA-512 are both SHA-2. If one is broken, it is likely that
the other is as well.

Again, you know that, but do the users you're trying to help by deprecating sha1()? I'm a reasonably experienced developer, and I have no idea why SHA-512 would exist if it's not in some way "better" than SHA-256.

Regards,
--
Rowan Tommins
[IMSoP]

37

On Fri, Jul 26, 2024, at 15:02, Tim Düsterhus wrote:

HI

On 7/26/24 14:50, Rob Landers wrote:

$_SESSION[‘token’] = md5(uniqid(mt_rand(), true));

Exactly the md5-uniqid construction that is called out as unsafe in

the RFC and used in a security context.

In regards to hashing, this is likely fine; for now. There still isn’t an arbitrary pre-image attack on md5 (that I’m aware of). Can you create a random file with a matching hash? Yes, in a few seconds, on modern hardware. But you cannot yet make it have arbitrary contents in our lifetime. The NSA probably has something like this though, but if so, this isn’t widely known.

Neither collision-, nor pre-image resistance is relevant here. The

attack vector is a brute force attack / an attacker guessing the token

rather than the token’s contents.

You do realize that GUID and md5 hashes are the same size? One does not simply “guess” a GUID or an md5 hash. gravatar used md5 until a couple of years ago, and had millions? billions? of emails addresses and zero collisions.

That being said, this is just randomly creating a random id without leaking it’s internal construction, no different than putting an md5 in a UUID-v8. The real issue here is the use of uniqid() and rand(), making it quite likely (at scale, at least) that a session id will overlap with another session id.

The point is that it showcases a fundamental misunderstanding of what

MD5 (or really any other hash algorithm) does for you. The application

of the MD5 does not make the token more random or more unique or

whatever positive adjective you would like to use. It would be equally

strong (or rather weak) if the output of uniqid(mt_rand(), true) was

used directly.

Yes, it does, but probably not how you think. It would be much weaker to leak the internal construction (uniqid(mt_rand(), true)) because then someone could literally guess a working id if they knew when the id was generated (depending on the size of mt_rand, rate limits, etc).

By wrapping it in an md5, it is literally unguessable how it is constructed, but the construction is still crap in this case.

As per Kerckhoffs’s principle, the security of the algorithm must not

rely on the attacker not knowing how it’s implemented. Given how

prevalent constructions like the above are, an attacker could make an

educated guess about how it looks like and match their own token against

a precomputed table to find out if it matches.

In this example, an ID is being constructed. If it needs uniqueness, the ID is being constructed incorrectly, but if you could argue that a GUID would fit the bill here, md5 has more “entropy” than a GUIDv4. But due to how the md5 is constructed, it actually has less entropy. So, I think we both can agree that the construction is crap. However, the usage of md5 doesn’t matter here. If it really bothers you, craft a GUIDv8 from it.

But to Kerckhoffs’s principle, that is in regards to encryption … this is not encryption.

— Rob

38

On Fri, Jul 26, 2024, at 11:11 AM, Christoph M. Becker wrote:

On 26.07.2024 at 12:03, Gina P. Banyard wrote:

Stephen Rees-Carter, a security expert that has performed countless security audits on Wordpress and Laravel websites, would like to disagree with the fact that it is not enough of a good reason. [1]
A warning on a documentation page is useless, as nobody is forced to read it.

Right, but even a deprecation notice is likely to be ignored by those
(either use the shut-up operator, or use hash("md5), or maybe a polyfill
to support old PHP versions), so the deprecation wouldn't help in such
cases.

(I've recently seen a new release of a software which still uses
<https://www.openwall.com/phpass/&gt;\. Apparently, the notice to prefer
the password_*() API has been ignored or overlooked.)

On the other hand, I'm quite confident that a deprecation could be
useful for some developers, who would at least reconsider the use of
md5/sha1 hashes, but just have overlooked this; although some static
analysis should report respective issues. However, there is certainly
code without any static analysis, where at least this discussion appears
to be helpful, e.g. our php-sdk-binary-tools might reconsider their use
of md5() and md5(uniqid())[2].

Note that I'm not against these deprecations, but I'm also not strongly
in favor. I see valid arguments from both proponents and opponents.

[1] x.com

[2] <Issues · php/php-sdk-binary-tools · GitHub;

Cheers,
Christoph

One thing to remind people about, the deprecations for md5(), sha1(), and uniqid() explicitly say they cannot be outright removed before PHP 10. That's at least 6 years away. That gives a loooooong time for documentation, tutorials, instructions, and code to be updated.

That long deprecation period is the reason why I was comfortable voting yes. This isn't something that would happen tomorrow. It would be in at least two presidential elections from now.

--Larry Garfield

39

On 26.07.2024 at 15:13, Rowan Tommins [IMSoP] wrote:

On Fri, 26 Jul 2024, at 12:58, Tim Düsterhus wrote:

CRC32 does not claim to be a cryptographically secure hash algorithm.
Its use case is completely different.

As an inexperienced user looking at the PHP manual for hash() and hash_algos(), how would I know that? It's right there in the list, just after something called "adler32".

Well, you are supposed to also check the hash_hmac() documentation,
where a changelog entry for 7.2.0 states:

| Usage of non-cryptographic hash functions (adler32, crc32, crc32b,
| fnv132, fnv1a32, fnv164, fnv1a64, joaat) was disabled.

Or maybe we should fix <Issues · php/doc-en · GitHub.

Cheers,
Christoph

40

On Fri, 26 Jul 2024, 15:22 Larry Garfield, <larry@garfieldtech.com> wrote:

That long deprecation period is the reason why I was comfortable voting yes. This isn’t something that would happen tomorrow. It would be in at least two presidential elections from now.

Real elections or rigged elections? :grin: