On Mon, May 7, 2012 at 10:31 AM, Kris Craig <kris.cr...@gmail.com> wrote:
> On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks <arvids.godj...@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 == 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 пользователь "Tjerk Anne Meesters" <datib...@php.net> > > написал: > > > Forgive me if I'm missing something, but why are people using == for > security-sensitive string comparisons (like hashed passwords) in the first > 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 == on string > 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 10 > 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 lingering > 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 PHP > 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=54547) implements this behavior -- Ferenc Kovács @Tyr43l - http://tyrael.hu
