October 2013 private data security issue/id

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 56% 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

Informasi kontak

Jika Anda memiliki pertanyaan, hubungi kami via email ke:

accountsecurity(_AT_)wikimedia.org

Anda juga dapat menghubungi Yayasan Wikimedia di:

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


Pertanyaan dan Jawaban

Apa yang terjadi?

1 Oktober 2013, kami mempelajari tentang kesalahan konfigurasi pada salah satu basis data kami yang menjadikan informasi pengguna pribadi tertentu untuk sekitar 40.000 pengguna proyek Wikimedia dapat diakses oleh sukarelawan dengan akses ke infrastruktur “LabsDB” Wikimedia.

Apakah LabsDB itu?

LabsDB, yang diluncurkan bulan Mei 2013, dirancang guna memberikan kemampuan pada sukarelawan untuk menulis alat dan membuat laporan yang menggunakan data dari data basis kami dalam waktu-nyata. Hal ini mendukung inovasi bawah-atas oleh komunitas Wikimedia.

Siapa yang menemukan masalah ini?

Masalah ini ditemukan dan dilaporkan oleh sukarelawan tepercaya, dan akses ke data yang bermasalah dicabut dalam beberapa menit setelah pelaporan.

Laporan bug dapat ditemukan di sini.

Informasi apa saja yang tersedia bagi pengguna LabsDB?

Ada empat jenis informasi pengguna yang berpotensi tersedia: alamat email pengguna, hash sandi, pengenal sesi (digunakan agar Anda tetap masuk), stempel waktu masuk terakhir.

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.

Kesalahan konfigurasi ini tidak memengaruhi data pemberi mana pun, dan tidak ada data privat lain yang tersedia.

Berapa lama informasi itu tersedia?

Waktu ketersediaan data ini mulai 29 Mei sampai 1 Oktober 2013.

Mengapa waktu untuk menemukan kesalahan konfigurasi sangat lama?

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.

Siapa yang akan memiliki akses ke informasi tersebut?

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

Pada 1 Oktober, sebanyak 228 pengguna memiliki akses ke LabsDB.

Jenis protokol keamanan apa saja yang dimiliki untuk mencegah ketersediaan data pengguna?

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.

Apakah seseorang mengakses informasi pribadi?

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.