-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aw, come on, why is there so much contention about such a simple issue? And yes, I did slip when I started talking about birthday attacks. Sorry about that.
- From the way I see it, then, the primary objections with migrating are that:
* All this hashing and salting tomfoolery makes no difference because the only way an attacker could possibly get the hashes is if they hacked into the server or a developer with full-read access pulled the hashes. * The current way is not broken, because there have been no pre-image attacks developed for MD5 * Effort spent on migration would be better spent on HTTPS * The security benefit is miniscule, compared to other possible strategies such as encouraging strong passwords * And that I have no clue what I'm talking about (I like to think that I at least have some clue)
There are some periphery issues surrounding SHA256:
* SHA-256 is not as widely deployed, so it might have some fatal weaknesses. (it's unlikely, though, because it is still based off of SHA-1) * SHA-256 would require a pure-PHP implementation which might have bugs (Due to the avalanche effect, however, any bug should be glaringly obvious. Furthermore, the algorithm is small enough so that a full code audit would not be difficult to do (think <15kb))
My arguments for migrating are:
* Defence in depth: it is true that there are a number of elements that already potentially should "solve" the problem, but this argument taken to the extreme would mean there would be no need to hash or salt the password at all: after, anyone who has access to the database could just change it themselves! But I'm sure most reasonable people here agree that hashing the password is better than no protection at all, even if it doesn't seem to make a difference. * It saves effort later: By adding support for multiple hashing techniques, and building the framework necessary to migrate these hashes, we reduce the cost of any other hash migrations we have to do in the future down. If done properly, a future migration could be done by specifying a new hash function, and the code from the previous migration would do all the work. * It is forward thinking: attacks against hashing schemes never grow worse: they only get better, as processing power, memory capabilities and knowledge of attacks increase.
It's no problem if we don't, of course. The strangeness of MediaWiki's current hash function should, for now, prevent people from using rainbow tables to find the password (even though you reduce entropy by double-hashing). But, as I said, defense in depth!
Now, about that password security indicator...