[RFC] [VOTE] Deprecations for PHP 8.4

On Fri, 2024-07-26 at 00:44 +0200, Juliette Reinders Folmer 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().

On 2024-07-28 00:36, Rowan Tommins [IMSoP] wrote:

I'm just looking at the manual's version information about when the functions were introduced. Seems pretty unambiguous: md5, sha1, hash: versions 3, 4, and 5 (via PECL).

str_contains and str_starts_with - because it's convenient to have straightforward functions for common use cases.

Because there weren't any purpose-built functions that did the job, forcing users to use other functions in expensive ways for what is internally a pretty simple task. There is a purpose-built function for hashing.

Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions for both, and then when SHA4 comes along (as it inevitably will) another standalone function for one of its variants?

Or leave them them the 60-piece set (which includes flat-head and Phillips screwdrivers, so they're not being taken away), and write some tips on how to use it correctly.

I rise in support of this mindset. Some of us like to draw inspiration from other languages, and in that vein one of the things that makes Go such a joy to program in is the fact the Go team continues to add "convenience" functions with every new 6 month release. Many (all?) of the functions the Go team adds could have been written in "userland" but they represent such common use-cases that the Go team decided to make them easy and obvious. They even soft deprecate functions and structs that are not ideal and replace them with ones with better names and better signatures. If Go had started with the string and array functions PHP has today they would almost certainly replaced them by now, ~15 years into Go's tenure. It is a shame that PHP's culture is so hostile towards adding functionality that could also be added in userland, especially when that functionality would simplify and standardize algorithms that are non-obvious and/or too easy to implement incorrectly. If the PHP culture embraced moving common use-cases into core it would make PHP much more pleasurable to program in and make it much less likely that PHP programs would have bugs and/or security vulnerabilities.

Yes. Yes, And Yes. And ideally within a `\PHP` namespace. -Mike P.S. But as we know a standardized `\PHP` namespace is apparently never going to happen although for the life of me I still cannot understand why not — and I was here during the voting down of that RFC ~4 years ago — given how so many other languages had done the equivalent.

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] https://socket.dev/blog/openssf-warns-of-reputation-farming-using-closed-github-issues-and-prs rr

Am 26.07.2024, 12:03:53 schrieb Gina P. Banyard <internals@gpb.moe>:

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 26.07.2024 at 12:03, Gina P. Banyard wrote:

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/>. 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.

[2] <https://github.com/php/php-sdk-binary-tools/issues/21> Cheers, Christoph

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

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]

People who work in emergency rooms think that motorcycles are the ultimate evil and should be banned, because emergency room workers are the ones who see all of the carnage of the small percent who wreck their motorcycles, and they see none of motorcycling's upsides. Similarly, security experts see everything through the lens of security issues, because they see the problems FAR more often than everyone else. And as security expertise, they don't see code through other lenses where security is not an issue. Not saying the input of a security experts is not useful, but one man's input is only one side of the story, just like emergency room workers vs. motorcycles.

Explicitly stated, that is a straw man argument, which Rowan already called out. Different people weight risks, costs, and benefits differently, and just because you might feel your approach for addressing security concerns should eclipse anyone else's approach and all other concerns does not mean your approach exists at the peak of the moral high ground. Every time PHP deprecates software it places the burden and the cost of remediation on anyone and everyone who continues to use the software that requires the deprecated items. Those who are zealously security-first generally dismiss those burdens and cost of remediation — because they do not have to be burdened by then nor pay the costs — and so they shift them to everyone, including those who are using functions properly. Those more pragmatic balance that burden and cost with the potential burden and costs that deprecating can impose. And in the case of md5() where public code on GitHub shows almost 1 million uses, that imposed burden and cost is pretty large. But ignoring the burden and cost, is it strongly arguable that deprecating md5() wouldn't even fix the security problems in most cases as those you most want to force to fix things will the ones more likely to just create a polyfill and move on. As many has already stated on this thread. Kudos to Tim Düsterhus for identifying https://www.phptutorial.net/php-tutorial/php-csrf/ and https://www.php-einfach.de/php-tutorial/die-wichtigsten-php-funktionen/ but his takeaway for an action item was less inspiring. He argued those articles support deprecations when it seems to me the more obvious takeaway after finding those articles would be to reach out to those websites — as well as others publishing insecure information — and provide them with updated content to replace the content they are currently publishing with content that is promotes secure practices. Getting those websites updated is likely to have far more positive impact for new PHP developers learning to do things "the right way" then forcing them to update their code where they'll likely just use hash("md5"). Further, rather than shift the burden of remediation to everyone else, why not write a crawler that can automatically and proactively submit PRs to all the code out there using md5(), etc. so that most people only need to accept the PR to update their code, and make is available as a CLI for internal use? I know it is not that simple to remediate, but who do you expect will know how to do that better than those on PHP internals. Certainly not most GitHub repo owners. Besides, the PR could say "Review your code we are proposing the change, and if you are confident that your uses are secure then do not apply this PR. But if you are not sure they are secure then just apply the PR, test it, and then you'll certainly be safer." Rather than just take a low-effort, feel-good action for security theater, if the PHP community REALLY cares about security for its users it would take a pro-active, higher-effort approach to addressing the concern. The WordPress community implemented at least one successful technology-supported "marketing" campaign to move its user base in the past, one of which was the "Serve Happy" campaign to get people to update their version of PHP (how ironic!): https://make.wordpress.org/core/features/servehappy/ Why not create a working group to promote a "SERVE SECURELY" campaign modeled after WordPress's "Serve Happy" campaign, and do your best to help people remediate their security issues? Hell, imagine the free press and industry-wide exposure that such as campaign would provide as a way to educate PHP programmers on the dangers of misusing md5() and other insecure approaches? It is also strongly possible you could even get significant sponsorship for such as campaign to pay for some more developer time to address the problem. It almost certainly could be seen as a feel-good thing for big industry players to support. Frankly, if the pro-deprecation voters in the PHP community are not willing to pursue an initiative that proactively seeks to help users remediate and educate users about security concerns then I would argue *they* do not really care about security of PHP users but instead are only willing to paying lip service to it. #fwiw TLDR;? Use a carrot, not a stick. -Mike

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

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.

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

The NSA likely owns "Let's Encrypt" and can therefore MitM every TLS site on the internet.

This. I'm not going to quote everything, but I read through the comments from today and would say this: 1) This seems very much like the people in support of these deprecations are trying to push PHP to enforce *policy* on developers, rather than simply providing tools. 2) PHP should provide good documentation, but should not try to force every user to do something "best practice" by renaming functions. 3) If a websever/host updates the PHP version and the code breaks, the last thing a dev is looking for is "what's the best practice to refactor this code". The dev is thinking, "our site is down, the boss/client is angry, what's the fastest band-aid I can slap on this to get the site up again". Thus: Provide tools, not policy. Provide good documentation.

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

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 <https://github.com/php/doc-en/issues/3616>. Cheers, Christoph

Hi On 7/26/24 15:13, Rowan Tommins [IMSoP] wrote:

I am not expecting that from a beginner. I am expecting two things: 1. That the beginner switches to a tutorial that does not emit any error messages or warnings, because they realize that the tutorial is not as good as it claims to be. 2. That (1) leads to the outdated tutorials falling out of favor with regards to search engines or alternatively that the outdated tutorials are updated to no longer be outdated.

I expect the inexperienced user to look at existing tutorials or code snippets, rather than the reference documentation: If they are inexperienced, they would not even know what to look for in the documentation. That also ties into (1): I hope that the deprecation results in better tutorials / making bad tutorials less attractive. Of course that doesn't mean we shouldn't improve the documentation, and I'm seeing that Christoph and Jim already started doing so.

See above. Also: Really any choice from the SHA-2 or SHA-3 family is better than both MD5 and SHA-1 and I would expect users to generally gravitate towards things they have heard about before and you really need to try hard not to have heard about SHA-256 before. Wikipedia is also helpful regarding this topic. Best regards Tim Düsterhus