Hi On 7/24/24 05:58, Peter Stalman wrote:
is already quite specific. We're talking about end users who are rolling their own security implementations and are unaware of the security risks but somehow know how to use these functions without reading the documentation and warnings.
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.
As an example, using md5_file() to implement a cache buster is fine, but a less-experienced developer may believe that md5_file() uniquely identifies the file contents and use it in a way where strong collision-resistance against an adversary is required.
On the other hand, who will be impacted by these deprecations? Potentially everyone, as these are included in many projects and in many vendor packages. It's busy work for the people who aren't affected. Sure, eventually, it will all be sorted out as CI warnings slowly subside because of this.
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.
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', …).
Best regards Tim Düsterhus
