On Thu, Jul 25, 2024 at 8:33 AM Tim Düsterhus <t...@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
