Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124599
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
Date: Thu, 25 Jul 2024 23:35:14 -0700
Message-ID: <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005bc032061e20b7c1"
From: sarkedev@gmail.com (Peter Stalman)

--0000000000005bc032061e20b7c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 25, 2024 at 8:33=E2=80=AFAM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> 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', =
=E2=80=A6).
>

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

--0000000000005bc032061e20b7c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jul 25, 2024 at 8:33=E2=80=AFAM T=
im D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be<=
/a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">No, we are talking about end users who are follow=
ing tutorials that were <br>
written when PHP 4 was the most recent PHP version.<br>
<br>
We are also talking about end users who look at existing code bases for <br=
>
&quot;inspiration&quot;, see md5() used, notice that the output looks rando=
m and <br>
use it, believing they know what they are doing, but in that process use <b=
r>
it in a way that is insecure.<br></blockquote><div><br></div><div>Hi Tim,</=
div><div><br></div><div>How prevalent=C2=A0is this exactly? PHP 4 ended sup=
port in 2008.=C2=A0 I think putting warning labels on these things in the d=
ocs is enough, but we can&#39;t go around locking up every kitchen knife ju=
st because there are some idiots out there who read a=C2=A0book from the 50=
s about the=C2=A0war.</div><div><br></div><div>And like I said previously, =
this change isn&#39;t what is going to determine if those people will write=
 good, reliable, secure code.=C2=A0 If their learning insticast can&#39;t s=
ee past a blog tutorial from 20 years ago, not even to look up the function=
 in the manual, they will not ever achieve that.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">
I&#39;m positive that even existing projects written by experienced <br>
developers would benefit from re-checking if their use of MD5 and SHA-1 <br=
>
is actually safe instead of assuming that this is the case, when the <br>
specific functionality has been untouched for the last 10 years.<br></block=
quote><div><br></div><div>You can say this about pretty much every software=
 project in existence, regarding anything.=C2=A0 I just don&#39;t think it&=
#39;s up to PHP to mandate these checks.=C2=A0 If you want to create a fund=
 for developers to go review their code on the=C2=A0clock, fine, but don&#3=
9;t force it on them.=C2=A0 Might as well deprecate everything=C2=A0each ma=
jor version to force people to rewrite their projects to &quot;current best=
 practices&quot;.=C2=A0 If I wanted to do that, I&#39;d just use the JS fra=
mework of the month.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
Looking back at my own code, I&#39;m seeing places where using SHA-1 is not=
 <br>
strictly insecure, but where a stronger hash function nevertheless would <b=
r>
have been more appropriate, if only to simplify code audits. I just used <b=
r>
sha1(), because it was temptingly convenient compared to hash(&#39;sha256&#=
39;, =E2=80=A6).<br></blockquote><div><br></div><div>sha1 was the &quot;pro=
per&quot; alternative to md5, until it wasn&#39;t. md5 superceeded=C2=A0crc=
32, which btw, why isn&#39;t=C2=A0that on the hit-list?</div><div><br></div=
><div>You&#39;re using sha256? It&#39;s soooo outdated, use sha512 and key =
it with hmac, you casual=C2=A0/s</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">SHA-1 is a deterministic algorithm, thus it is =
unable to generate a<br>random UID. Whatever this code is doing can most li=
kely be more reliably<br>achieved in a different way.</blockquote><div><br>=
</div><div>ALL hashing functions are deterministic.=C2=A0 That&#39;s the wh=
ole point, and applies to sha256 just the same.=C2=A0 You want to be able t=
o hash the same content and get the same hash.=C2=A0 Just the complexity an=
d chance of collision=C2=A0changes.=C2=A0 The reliability and security you =
are concerned with in this scenario really depends on what randomness you f=
eed it.</div><div><br></div><div>Thanks,</div><div>Peter</div><div><br></di=
v><div><br></div></div></div>

--0000000000005bc032061e20b7c1--