Page MenuHomePhabricator

Password hash weakening under special circumstances
Closed, ResolvedPublic

Description

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

Details

Reference
bz35961

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:18 AM
bzimport set Reference to bz35961.

Fixing commit rMW76881580cd9c

Attached:

I do not think it is serious enough to trigger a new maintenance release.

Reedy added a comment.Apr 20 2012, 8:53 AM

(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.

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