The way cookies are done also needs to be changed.
And that leads to requiring the entering of your existing password in order to be able to change your password.
And that leads to providing a way to get around the above protection which leads to wanting a "security question and answer" and also adding some restrictions and notifications around attempts to change one's e-mail address.
And then there is the whole "sending password in plain-text" being required to login so we need to make login require (or at least support and probably strongly encourage) https.
And that leads to replacing the "login nodelet".
And nobody who actually currently does any significant work on maintaining this site was around when whoever made that first decision to not bother to hash passwords (as far as I know).
And tons of people have gotten their password e-mailed to them and not raised a tantrum like several people have recently so "plain-text passwords" hasn't been much of a hot topic over all these years.
And then there is that just using Perl's crypt (as suggested) would have meant that most (or certainly a large fraction) of the passwords I've seen would have been easily found anyway with standard dictionary attacks.
And even if I'd chosen a password that I was confident wouldn't be found in a 'crack' dictionary, I'd still go change any places where I'd re-used it once the hacking of the site was reported (I'd just be less panicked while doing so).
(But, yes, hashing passwords is an obvious best practice and something we regret not implementing sooner.)
In reply to Re^5: Status of Recent User Information Leak (minutes)