October 2013 private data security issue

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

Other languages:
العربية • ‎Deutsch • ‎Zazaki • ‎English • ‎español • ‎suomi • ‎français • ‎magyar • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎한국어 • ‎Nederlands • ‎occitan • ‎polski • ‎português do Brasil • ‎русский • ‎Türkçe • ‎українська • ‎中文

On October 1, 2013, we learned about an implementation error that made private user information (specifically user email addresses, password hashes, session tokens, and last login timestamp) for approximately 37,000 Wikimedia project users, accessible to the volunteers with an account to Wikimedia "LabsDB" infrastructure.

LabsDB, launched in May 2013, is designed to give volunteers the ability to write tools and generate reports that make use of data from our databases in real-time. This supports bottom-up innovation by the Wikimedia community. As part of this process, private data is automatically redacted before volunteers are given access to the data. Unfortunately, for some of Wikimedia's wikis,[1] the database triggers used to redact private data failed to take effect due to a schema incompatibility, and LabsDB users had access to private user data for some user accounts in these specific wiki databases. As of October 1, 228 users have access to LabsDB, and the window of availability of this data was May 29, 2013 to October 1, 2013.

This issue was discovered and reported by a trusted volunteer, and access to the data in question was revoked within 15 minutes of the report. We have no evidence to suggest that the private data in question was exported in bulk or used for malicious purposes, but we cannot definitively exclude the possibility. As a precautionary measure, we have invalidated all affected user sessions, and are requiring affected users to change their password on their next login.

We have also sent an email notification to affected users with a confirmed email address.

We regret this mistake. LabsDB is still a new part of our infrastructure, and we will fully audit the redaction process, so as to minimize any risk of a future mistake of this nature.

Sincerely,
Erik Moeller
Vice President of Engineering & Product Development

  1. List of affected databases: aswikisource bewikisource dewikivoyage elwikivoyage enwikivoyage eswikivoyage frwikivoyage guwikisource hewikivoyage itwikivoyage kowikiversity lezwiki loginwiki minwiki nlwikivoyage plwikivoyage ptwikivoyage rowikivoyage ruwikivoyage sawikiquote slwikiversity svwikivoyage testwikidatawiki tyvwiki ukwikivoyage vecwiktionary votewiki wikidatawiki wikimania2013wiki wikimania2014wiki

Contact information[edit]

Should you have any questions, please contact us via email to:

accountsecurity at wikimedia.org

You can also reach the Wikimedia Foundation at:

Wikimedia Foundation, Inc.
149 New Montgomery Street
Floor 6
San Francisco, CA 94105
United States
Phone: +1-415-839-6885
Fax: +1-415-882-0495


Questions and Answers[edit]

What happened?

On October 1, 2013, we learned about a configuration error in one of our databases that made specific private user information for approximately 40,000 Wikimedia project users accessible to volunteers with access to the Wikimedia “LabsDB” infrastructure.

What is LabsDB?

LabsDB, launched in May 2013, is designed to give volunteers the ability to write tools and generate reports that make use of data from our databases in real-time. This supports bottom-up innovation by the Wikimedia community.

Who discovered the issue?

This was discovered and reported by a trusted volunteer, and access to the data in question was revoked within minutes of the report.

The bug report can be found here.

What kind of information was available to LabsDB users?

There were four types of user information that were potentially available: user email addresses, password hashes, session identifiers (used to keep you logged in), last log-in timestamp.

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. The passwords were hashed using the MD5 algorithm with a salt.

This configuration error did not affect any donor data, and no other private data was available.

How long was that information available?

The window of availability of this data was May 29, 2013 to October 1, 2013.

Why did it take so long to discover the configuration error?

Only a subset of our public wikis was affected by the redaction issue, and only a subset of private data was accessible. The redaction mechanism was tested and appeared to be working as intended, but a set of new wikis that were added with a small difference in their database schema caused the process to partially fail without notice, until a volunteer pointed out the discovery of the issue.

Who would have had access to that information?

Users of LabsDB would have potentially been able to access this user information, but we have no evidence to suggest that anyone did.

As of October 1, 228 users have access to LabsDB.

What kinds of security protocols do you have to prevent user data from being available?

As part of this process, private data is automatically redacted before volunteers are given access to the data. Unfortunately, for some of Wikimedia's wikis, the database triggers used to redact private data failed to take effect, and LabsDB users had access to private user data present for some users in these specific wiki databases.

Did anyone access personal information?

We have no indication that any third party actually accessed this information, only that it was potentially accessible to a LabsDB account holder. To the limited extent we're able, we have looked for such evidence but found no evidence to suggest that the private data in question was exported in bulk or used for malicious purposes, but we cannot definitively exclude the possibility.

Which were the affected databases?
  • aswikisource
  • bewikisource
  • dewikivoyage
  • elwikivoyage
  • enwikivoyage
  • eswikivoyage
  • frwikivoyage
  • guwikisource
  • hewikivoyage
  • itwikivoyage
  • kowikiversity
  • lezwiki
  • loginwiki
  • minwiki
  • nlwikivoyage
  • plwikivoyage
  • ptwikivoyage
  • rowikivoyage
  • ruwikivoyage
  • sawikiquote
  • slwikiversity
  • svwikivoyage
  • testwikidatawiki
  • tyvwiki
  • ukwikivoyage
  • vecwiktionary
  • votewiki
  • wikidatawiki
  • wikimania2013wiki
  • wikimania2014wiki
What have you done to remedy the configuration error?

Access to the data in question was revoked within 15 minutes of the report. As a precautionary measure, we have invalidated all affected user sessions, and are requiring affected users to change their password on their next login. We have also sent an email notification to affected users with a confirmed email address.

We will also fully audit the redaction process to minimize any risk of a future mistake of this nature.

I use the same password on other sites, should I change it there as well?

While only password hashes were potentially exposed to third parties, those are vulnerable to certain forms of brute force attacks that could recover passwords (especially if the password isn't particularly strong). We recommend that you change your password on any other site where it was used – ideally to a different one than you use on Wikimedia projects.