Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124608
Message-ID: <6c0baa01-68e5-4d74-bc4e-d6830ab5076d@bastelstu.be>
Date: Fri, 26 Jul 2024 13:58:48 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: Peter Stalman <sarkedev@gmail.com>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
 <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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.

Further down on the first page I find 
https://www.tutorialspoint.com/php/php_mysql_login.htm, 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 
https://www.php-einfach.de/php-tutorial/die-wichtigsten-php-funktionen/ 
("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