Проблема безпеки приватних даних у жовтні 2013 року

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page October 2013 private data security issue and the translation is 46% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎Türkçe • ‎Zazaki • ‎español • ‎français • ‎italiano • ‎magyar • ‎occitan • ‎polski • ‎português do Brasil • ‎română • ‎suomi • ‎русский • ‎українська • ‎العربية • ‎中文 • ‎日本語 • ‎한국어

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

Контакти

З будь-якими запитанням, будь ласка, напишіть нам листа на електронну адресу:

accountsecurity(_AT_)wikimedia.org

Ви також можете зв'язатися з Фондом Вікімедіа таким чином:

Wikimedia Foundation, Inc.
149 New Montgomery Street
Floor 6
San Francisco, CA 94105
United States
Телефон: +1-415-839-6885
Факс: +1-415-882-0495


Питання і відповіді

Що сталося?

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.

Що таке 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.

Хто виявив проблему?

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.

Якого роду інформація була доступна користувачам LabsDB?

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.

Як довго була доступною ця інформація?

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

Чому пройшло стільки часу перед виявленням помилки конфігурації?

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.

Хто міг мати доступ до цієї інформації?

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.

Які типи протоколів безпеки у вас є для унеможливлення доступності даних користувачів?

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.

Хто отримав доступ до особистої інформації?

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.

Які бази даних постраждали?
  • 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
Що ви зробили для виправлення помилки конфігурації?

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.

Я використовую цей же пароль на інших сайтах, чи треба мені його і там міняти?

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.