Possibly related: "Jimmy Wales launched an investigation to determine if any of the pseudonyms who edit the world's biggest encyclopedia belong to Edward Snowden."
That incident was a Jimbo Classic. First, he clearly asks other users to feed him any information they have about Snowden editing Wikipedia. Then, he's told that could be a violation of Wikipedia's long-standing policies against "outing" users who haven't self-identified. Then, the back-pedaling begins. Ultimately, Jimbo ends up at this fake position that he "strongly" supports Snowden's privacy, and how Wales was asking "only" for publicly-acknowledged information, etc. Jimmy Wales must wake up each day and ask, "What shall I lie about today?"
Not really familiar with the code base but I took a peek at the git repo for MediaWiki[1] (the code for Wikipedia itself). It looks like it's uses a salted md5[2].
Reading through the code a bit, apparently this is the "new" way they're doing things. For older accounts it's just md5 (either with no salt or the userid as the salt, toggled by a global config). Not good ...
The only "not good" part here is using MD5, but, well – that code was written ten years ago, and then MD5 was AFAIK considered perfectly secure. There's an outstanding bug from 2011 about replacing it with something better (https://bugzilla.wikimedia.org/show_bug.cgi?id=28419).
edit: I asked the primary Wikimedia Foundation security guy (Chris Steipp) on IRC about that bug and he said he's working on it. One good thing to come out of all this ;)
> The only "not good" part here is using MD5, but, well – that code was written ten years ago, and then MD5 was AFAIK considered perfectly secure.
It's been a terrible idea to use MD5 (or any other generic hash function) directly for hashing passwords for years. Certainly well before 2003. PBKDF2 has been around since at least 2000 and bcrypt since 1999. Choosing a "better" hash function itself isn't enough. It'd just as bad if it was SHA-1 instead. A large number of rounds is needed to lengthen the time needed to test a guess which is what PBKDF2 and bcrypt do[1].
> There's an outstanding bug from 2011 about replacing it with something better (https://bugzilla.wikimedia.org/show_bug.cgi?id=28419).
edit: I asked the primary Wikimedia Foundation security guy (Chris Steipp) on IRC about that bug and he said he's working on it. One good thing to come out of all this ;)
Well that's good news. It's sad that it takes events like this to get security fixes prioritized but at least they do.
Somewhat related, this is yet another example of why OSS is great. With no experience with the code base it took all of 5 min to figure out how they handle it and get a idea of the effort to fix it. It looks like they already have versioning in place (the A/B) so hopefully it'd be easy to add a C with a better approach (and make it the default).
[1]: Or even better scrypt which also increases the memory needed to compute the hash based on the work factor.
Password hashes, not passwords. "Note that password hashes do not reveal passwords in cleartext; if any third party successfully obtained a copy of the hashes, they would need to mount a brute force attack in order to obtain valid passwords from the hashes, which is most likely to be successful in the case of very simple, insecure passwords."
Password Hashing is a pointless term whenever password leaks occur. Non-technical users will have no idea what it means, and technical people will ask, "It's not MD5, SHA-bleh, CRC32, right? Also it's salted (assuming the hashing function does not generate it's own salt) right?"
I added this information to the page (anyone can edit it!, if you have an account). They were hashed with MD5 with a salt, which is not great, but not a huge catastrophe either.
http://www.examiner.com/article/jimmy-wales-breaks-wikipedia...