JD.com में 2013 की डेटा सेंध
JD.com में 2013 की डेटा सेंध चीन स्थित इस ई-कॉमर्स सेवा के खातों से जुड़े डेटा से संबंधित है। बाहरी स्रोत के एक सत्यापित सेंध रिकॉर्ड में 2013 की इस घटना के लिए 7,74,49,341 अलग-अलग ईमेल पते दर्ज हैं। घटना की सटीक तारीख ज्ञात नहीं है। दिसंबर 2016 में कंपनी की घोषणा पर उस समय की रिपोर्टों के अनुसार, JD ने लीक की पुष्टि की, इसके लिए Apache Struts 2 की 2013 की एक कमज़ोरी को ज़िम्मेदार बताया और उन ग्राहकों को सूचित किया जिन्हें जोखिम में माना गया था।
उजागर हुए डेटा के प्रकार
4- ईमेल पते
- पासवर्ड
- फ़ोन नंबर
- उपयोगकर्ता नाम
इस डेटा उल्लंघन के बारे में
सत्यापित बाहरी डेटासेट में कौन-सा डेटा है?
सत्यापित रिकॉर्ड के अनुसार, 13 GB डेटा में संरचित डेटा की चार श्रेणियाँ हैं: ईमेल पते, यूज़रनेम, फ़ोन नंबर और SHA-1 पासवर्ड हैश। SHA-1 मान सादे पाठ में लिखा पासवर्ड नहीं होता, लेकिन पासवर्ड संग्रहण के आधुनिक मानकों के अनुसार यह कमज़ोर है। छोटे या कई जगह इस्तेमाल किए गए पासवर्ड के लिए ऑफ़लाइन अनुमान लगाकर उनका पता लगा लेने का जोखिम बना रहता है।
2016 की रिपोर्टों में उस समय प्रसारित हो रहे लगभग 12 GB के पैकेज में अधिक तरह के फ़ील्ड होने का भी उल्लेख था, जिनमें QQ खाते और पहचान संख्याएँ शामिल थीं। उस पैकेज के आकार और उसमें शामिल फ़ील्ड के दायरे को सत्यापित बाहरी डेटासेट के समान नहीं बताया गया है। इसलिए उन अतिरिक्त दावों को इन चार संरचित श्रेणियों में शामिल नहीं किया गया है। भुगतान कार्ड, ऑर्डर का इतिहास और बैंक खाते भी मौजूदा संरचित डेटा के दायरे में नहीं हैं।
तारीख और 7,74,49,341 के आँकड़े का क्या अर्थ है?
स्रोत सेंध की सटीक तारीख नहीं बताते, इसलिए तारीख वाले फ़ील्ड में 1 जनवरी 2013 केवल वर्ष दर्शाने के लिए रखा गया प्लेसहोल्डर है। इससे यह साबित नहीं होता कि घटना 1 जनवरी को हुई थी। दिसंबर 2016 कंपनी के बयान और बिक्री के लिए पेश किए गए डेटा पैकेज के बारे में रिपोर्टों का समय है, किसी अलग सेंध की तारीख नहीं।
7,74,49,341 का आँकड़ा सत्यापित बाहरी डेटासेट में मौजूद अलग-अलग ईमेल पतों की संख्या दर्शाता है। यह खातों, लोगों या स्रोत फ़ाइलों की कुल पंक्तियों की गिनती से अलग माप है। प्रोडक्शन सिस्टम में JD के लिए कोई इम्पोर्ट जॉब नहीं है, और न ही ईमेल, पासवर्ड, फ़ोन नंबर या यूज़रनेम का स्थानीय रूप से इंडेक्स किया गया कोई डेटासेट है। इसलिए इस आँकड़े को स्थानीय कुल संख्या के रूप में प्रस्तुत नहीं किया गया है।
स्रोतों की कड़ी कैसे स्थापित की गई?
सत्यापित सेंध रिकॉर्ड से ईमेल पतों की सटीक संख्या, चार फ़ील्ड और SHA-1 संबंधी विवरण मिलते हैं। TechNode की 12 दिसंबर 2016 की रिपोर्ट में WeChat पर कंपनी की आधिकारिक घोषणा का लिंक है और यह बताया गया है कि JD ने 2013 की घटना की पुष्टि की थी। सत्यापित रिकॉर्ड में पहले लिंक किया गया एक अन्य द्वितीयक पृष्ठ अब 404 लौटाता है, इसलिए उसे सार्वजनिक स्रोत के रूप में इस्तेमाल नहीं किया गया है।
उपयोगकर्ता खाते से जुड़े जोखिम को कम करने के लिए क्या कर सकते हैं?
यदि 2013 में JD.com पर इस्तेमाल किया गया पासवर्ड किसी अन्य सेवा पर भी इस्तेमाल किया गया था, तो उस सेवा पर उसे बदलकर ऐसा पासवर्ड रखना चाहिए जो कहीं और इस्तेमाल न हो। जहाँ उपलब्ध हो, बहु-कारक प्रमाणीकरण भी चालू करना चाहिए। डिलीवरी, रिफ़ंड, प्रचार या पासवर्ड रीसेट के अप्रत्याशित संदेशों में दिए गए लिंक खोलने के बजाय, उपयोगकर्ताओं को JD का पता सीधे खोलना चाहिए।
ईमेल पते का मिलान होना इस बात का प्रमाण नहीं है कि पासवर्ड सादे पाठ में था, किसी खाते पर अनधिकृत कब्ज़ा हुआ था, या भुगतान और ऑर्डर का डेटा उजागर हुआ था। इस रिकॉर्ड का सत्यापित दायरा बाहरी डेटासेट में मौजूद ईमेल, यूज़रनेम, फ़ोन और SHA-1 पासवर्ड हैश के फ़ील्ड तक सीमित है।
सत्यापन और संपादकीय प्रक्रिया
LeakData घटना के नाम, तारीख, प्रभावित रिकॉर्ड की संख्या और उजागर हुए डेटा के प्रकारों का सुलभ स्रोतों से मिलान करता है। असत्यापित जानकारी को तथ्य के रूप में प्रस्तुत नहीं किया जाता, और नए साक्ष्य उपलब्ध होने पर रिकॉर्ड अपडेट किए जाते हैं।
छूटी हुई या गलत जानकारी की रिपोर्ट करें
