WikiPedia leaks user passwords to volunteers with access to the Wikimedia LabsDB | Hacker News Reader

WikiPedia leaks user passwords to volunteers with access to the Wikimedia LabsDB

meta.wikimedia.org

21 pointsunicornporn14 comments

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

http://www.examiner.com/article/jimmy-wales-breaks-wikipedia...

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

[1]: http://www.mediawiki.org/wiki/MediaWiki

[2]: https://github.com/wikimedia/mediawiki-core/blob/master/incl...

"New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923). Accoding to https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt salting was added and made default in MediaWiki 1.1, which is prehistory (something like 2003 or so).

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 ;)

> "New" here refers to "past-2008" – the salt was changed from using user ID then (https://mediawiki.org/wiki/Special:Code/MediaWiki/35923). >

> Accoding to https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt salting was added and made default in MediaWiki 1.1, which is prehistory (something like 2003 or so).

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

It shouldn't be possible to leak passwords, they should be hashed before being stored in the db surely...?

The very first line of the link lists

  user information (specifically, user email addresses,
  password hashes, session tokens, and last login timestamp)

So .. yes. Of course.

> "the database triggers used to redact private data failed to take effect due to a schema incompatibility"

I suppose this is an exception raised but it wasn't properly caught or one of the Python's "except Exception: pass" silence?

Probably just MySQL being MySQL. Never rely on database triggers.

Wait! So it just failed and returned everything?

I think the trigger just never, um, triggered. In my experience, MySQL fails silently far too often.

Reply on news.ycombinator.com