Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60503
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOpQSyrL_yVqEoxxpN+sWcQ9H6JjRQncpRnnG4BedjMRxrUqw@mail.gmail.com>
References: <CAPmfwEnMypV6DFRnRsnCvj+KQk1JG54TX3r1DNHQO3QQ0f+hjA@mail.gmail.com>
	<CAEZPtU4B0HpVrD4nzN6Cm+ogpza=qeyyfA1qSoRiyFF-dh6iFQ@mail.gmail.com>
	<CAORXhGLkKPY=GpfESDqiCVUhG4vZG7PmqK-v7780fGmvnQyeNw@mail.gmail.com>
	<4F847B8A.9010007@sugarcrm.com>
	<733bc8ea59cf6737563a62886e92fcb6.squirrel@www.l-i-e.com>
	<CAHMUw2Ft49f32di4nyOVWhzi-6Qn7u6yP4La2x_Wn2tZK-CHPA@mail.gmail.com>
	<CAL0xaBFKZySc4y72GS45t3En9g-6_RCzacvR3uf-N4fcaxymEA@mail.gmail.com>
	<CAKOpQSyrL_yVqEoxxpN+sWcQ9H6JjRQncpRnnG4BedjMRxrUqw@mail.gmail.com>
Date: Mon, 7 May 2012 10:56:40 +0200
Message-ID: <CAH-PCH41SSK89+y9NEXh+XgnoX+W370wZsxO1KAOiW-0FAvTCw@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Arvids Godjuks <arvids.godjuks@gmail.com>, Tjerk Anne Meesters <datibbaw@php.net>, 
	PHP Internals <internals@lists.php.net>, Richard Lynch <ceo@l-i-e.com>
Content-Type: multipart/alternative; boundary=e89a8ff25682cd81ec04bf6e722f
Subject: Re: [PHP-DEV] [off] PHP: a fractal of bad design
From: tyra3l@gmail.com (Ferenc Kovacs)

--e89a8ff25682cd81ec04bf6e722f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 7, 2012 at 10:31 AM, Kris Craig <kris.craig@gmail.com> wrote:

> On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks <arvids.godjuks@gmail.com
> >wrote:
>
> > Hello internals,
> >
> > I should voice my opinion that such things like comparing two strings
> > starting with numbers and that they resolve to actual integer/float for
> > comparation is bad, really bad. That just defies the logic and yealds
> > absolutly unexpected results. I pride myself that i know the juggling
> rules
> > well, but I'm shocked by this to say the least...
> > In my opinion this should change no matter the BC breaks it will create=
,
> > this one affects security big time. It's good I actually hash my
> passwords
> > in the MySQL and not on the PHP side, but I have seen hash comparations
> > with =3D=3D all the time. And now that this has been discussed in detai=
l I
> > expect this to be used as an attack method grow wide.
> > 07.05.2012 5:32 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C "Tjerk Anne Meesters" <datibbaw@php.net>
> > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
> Forgive me if I'm missing something, but why are people using =3D=3D for
> security-sensitive string comparisons (like hashed passwords) in the firs=
t
> place?!  If you needs something that's safe, isn't that what strcmp() and
> strcasecmp() are for?  For my part, I pretty much never use =3D=3D on str=
ing
> comparison, though admittedly that's probably just a matter of having
> having come from a C background before PHP.
>
> That being said, I agree that this *definitely* should be fixed if the
> examples cited are indeed accurate (I've been working with PHP for over 1=
0
> years and I was never aware of this bizarre behavior, either).  I don't
> know the history of this, but I at least would consider it to be a bug.  =
A
> rather large one, in fact; though I think some of the fears expressed are=
 a
> bit hyperbolic.  And if you're fixing a serious bug or security
> vulnerability, as a general rule of thumb, this automatically supercedes
> any concerns regarding BC breakage IMHO.  But if that really is a lingeri=
ng
> concern, I'd suggest targetting the fix for PHP 6, since people would (or
> at least should) expect that some PHP 5 code may behave differently in PH=
P
> 6 anyway given that it's a major release
>
>
I agree with Rasmus (and others) on this one (
http://www.mail-archive.com/internals@lists.php.net/msg57949.html), type
numeric conversion on strings on both sides should only happen if both
strings can be represented as numbers without losing data/precision.
if one or both of the two sides can't be converted to numeric without data
loss, then we should compare them as strings.
the patch from Cataphract (attached at https://bugs.php.net/bug.php?id=3D54=
547)
implements this behavior

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--e89a8ff25682cd81ec04bf6e722f--