Last modified: 2012-08-25 22:36:53 UTC
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.
Created attachment 10419 [details] Fixing commit 76881580cd9c30681aa65b228e0757c0515bbaa5
Gerrit change : https://gerrit.wikimedia.org/r/5204
I do not think it is serious enough to trigger a new maintenance release.
(In reply to comment #3) > I do not think it is serious enough to trigger a new maintenance release. It's done, so it might aswell go into the next set of maintenance releases which fix the issues related to the security fixes in the last set of releases
> I do not think it is serious enough to trigger a new maintenance release. No, not by itself. It should be backported to 1.19 and other maintained branches, though.
Backported to release branches with: REL1_19 : https://gerrit.wikimedia.org/r/5601 REL1_18 : https://gerrit.wikimedia.org/r/5602 REL1_17 : https://gerrit.wikimedia.org/r/5603
So it looks like this has been fixed in all of the maintained branches and this can be closed?
(In reply to comment #7) > So it looks like this has been fixed in all of the maintained branches and this > can be closed? closing