-----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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iD8DBQFFtpl9qTO+fYacSNoRAgr0AJ9cmGiUrIgl3fsfYG6N3tV47s4uswCeM4t2
ZueoZtM8ppOe2v1I7ZTrDLU=
=CKBM
-----END PGP SIGNATURE-----