

Comparing Hashes in PHP the Wrong Way - sarciszewski
https://eval.in/108854

======
LarryMade2
So both works out to something that looks like an exponent value, and then the
non-strct comparison evaluates them both as 0. The simple solution is ===.

A lot of luck having a hash with an 0e############ result.

~~~
sarciszewski
[https://twitter.com/voodooKobra/status/534724855103774721](https://twitter.com/voodooKobra/status/534724855103774721)

Comparing /^0e[0-9]{30}$/ with /^[0-9a-f]$/ gives you a chance of about 2.939
x 10^-9 in 1 (or about 0.0000002939%) of occurring. This is a naive
probability estimate.

Compared to a birthday collision, we can expect 6.28 * 10^28
0e############################## cases to occur for every hash collision.

Of course, there's also the possibility that 1e would act the same way, which
effectively doubles the odds.

------
opless
This is one reason that I don't regard PHP as anything more than a toy
language.

~~~
sarciszewski
Your elitism is noted and disregarded.

~~~
ainiriand
Indeed. This 'toy language' has accomplished many millions of strong websites.
It has some faults, but all languages has faults.

~~~
opless
Just because something is popular does not mean that it's "good". However it
is "good enough" for many things.

Much in the same way as BASIC was rubbish in the 8 but days. But the usage of
BASIC was near universal because it was near universal. Php is on virtually
every web hosting outfits web servers.

------
sarciszewski
Better: hash_equals()

Best: use password_hash() and password_verify()

~~~
opless
or use the "is this really equal" operator '==='

~~~
sarciszewski
[http://blog.astrumfutura.com/2010/10/nanosecond-scale-
remote...](http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-
timing-attacks-on-php-applications-time-to-take-them-seriously/)

For cryptographic secrets, password hashes, MACs, digital signatures, etc. use
a comparison operator that runs in constant time. Ergo, hash_equals()

