

WikiPedia leaks user passwords to volunteers with access to the Wikimedia LabsDB - unicornporn
https://meta.wikimedia.org/wiki/October_2013_private_data_security_issue

======
tikums
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...](http://www.examiner.com/article/jimmy-wales-breaks-wikipedia-
rules-hunt-for-snowden)

~~~
Thekohser
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?"

------
sehrope
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](http://www.mediawiki.org/wiki/MediaWiki)

[2]: [https://github.com/wikimedia/mediawiki-
core/blob/master/incl...](https://github.com/wikimedia/mediawiki-
core/blob/master/includes/User.php#L4492)

~~~
MatmaRex
"New" here refers to "past-2008" – the salt was changed from using user ID
then
([https://mediawiki.org/wiki/Special:Code/MediaWiki/35923](https://mediawiki.org/wiki/Special:Code/MediaWiki/35923)).
Accoding to
[https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt](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](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 ;)

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

> Accoding to
> [https://www.mediawiki.org/wiki/Manual:$wgPasswordSalt](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](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.

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

------
swang
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?"

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

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

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

------
yeukhon
> "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?

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

~~~
yeukhon
Wait! So it just failed and returned everything?

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

