Hash comparison should always be strict.

See http://phpsadness.com/sad/47 or https://bugs.php.net/bug.php?id=54547 for a recent revival.

We have a weak comparison in MediaWiki since the hash salting rework at r35923 (461a770a6fa5b43107d204c1230721751875236b). Goes back to 1.12.2 and 1.13.

This is not as bad as it sounds, as it's still a 2^18 preimage attack, and our salting and double md5 still keeps it strong.

Moreover, only hashes with only numeric characters are affected*, so
that's 10/16 ^ 32 = 0,000000294

• The e is also recognised, but as it has to appear at the end, and makes more digits significant in the later operation, doesn't seem to alter the result significantly.

Proposed summary:
If your salted password end up being completely numeric when represented in hexadecimal
(less than 1 password per 10 millions), it is also possible to login by providing another password that only matches the first 9 bytes (instead of the full 16 ones) if it turns out to also be completely numeric with your assigned salt (which is completely unknown).
The odds of finding an equivalent password with such characteristics, over a double md5
with an unknown salt, are really low. Even if the attacker broke into the servers and
robbed the salts, making use of this property would require a preimage attack of a partial md5 (2^18) with the output of another md5 hash, for which a full preimage would still be needed. Breaking the hashes using conventional attacks would be easier, so this is not a critical update.

Version: 1.20.x
Severity: minor