Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 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 13:41:27 +0300
Message-ID: <CAL0xaBEb7xeyqouZMyX-K-AUAWLs52-Hx=eDsKOwmx-7=FhTqQ@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.com>
Cc: Tjerk Anne Meesters <datibbaw@php.net>, PHP Internals <internals@lists.php.net>, 
	Richard Lynch <ceo@l-i-e.com>
Content-Type: multipart/alternative; boundary=e89a8f2357fdc251e604bf6fea89
Subject: Re: [PHP-DEV] [off] PHP: a fractal of bad design
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--e89a8f2357fdc251e604bf6fea89
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Easy - you see =3D=3D everywhere and =3D=3D=3D is used rarely, in docs you =
see it in
some places like strpos(). This is one thing that has to be communicated
through every channel available (including docs) with clear examples that
show why it should be used instead of =3D=3D.
Take me for example, I never had any idea that comparing two hashes that
start with numbers can generate a logical truth despite the hashes being
different. I haven't seen anything related to this in docs and never
stumbled upon in the internet, ever. So I use =3D=3D for comparing strings =
all
the time. Now I will change that because I have the knowledge why I should
use =3D=3D=3D instead of =3D=3D.
Well, now I do know, from this mailing list (witch is for PHP development)
- not many user-land developers read this list.

And in my previous message I said essentially the same as you did, just in
different words and style. English is not my native language and I have
been learning the British variant of it, so it's more formal that
American English :)

2012/5/7 Kris Craig <kris.craig@gmail.com>

>
>
> 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 passwrd=
s
>> 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 detail=
 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
>
> --Kris
>
>

--e89a8f2357fdc251e604bf6fea89--