Mac Forums डेटा में सेंध
Mac Forums में डेटा सेंध की यह घटना Apple और Mac उपयोगकर्ताओं की फ़ोरम साइट पर जुलाई 2016 में हुए खाता डेटा लीक से संबंधित है। इसके दायरे में लगभग 3,26,714 खाते हैं। इस रिकॉर्ड को सामुदायिक फ़ोरम के खातों में सेंध की घटना माना गया। उपयोगकर्ताओं को खाते, ब्रांड या डेटा फ़ील्ड के बारे में गलत धारणा न हो, इसलिए कंपनी, देश, क्षेत्र, वेबसाइट और डेटा श्रेणी के फ़ील्ड की अलग-अलग जाँच की गई। इस घटना का अर्थ यह नहीं है कि सीधे Apple खातों में सेंध लगी थी।
उजागर हुए डेटा के प्रकार
5- जन्म की तारीखें
- ईमेल पते
- IP पते
- पासवर्ड
- उपयोगकर्ता नाम
इस डेटा उल्लंघन के बारे में
विवरण से पुराने टेम्प्लेट के शीर्षक हटाकर उसे इस तरह व्यवस्थित किया गया कि उपयोगकर्ताओं को जोखिम, दायरा और ज़रूरी कदम सीधे समझ में आएँ। वेबसाइट का डोमेन mac-forums.com के रूप में दर्ज किया गया। इसमें प्रोटोकॉल नहीं जोड़ा गया, इसलिए वह प्रारूप नहीं रखा गया जिससे लिंक में https दो बार दिखाई देता। क्षेत्र को खुदरा व्यापार से बदलकर प्रौद्योगिकी फ़ोरम और Apple समुदाय किया गया; देश का मान वैश्विक रखा गया।
लीक हुए डेटा के प्रकार और जोखिम
इस रिकॉर्ड में ईमेल पते, उपयोगकर्ता नाम, IP पते, जन्मतिथियाँ और पासवर्ड शामिल हैं। आकलन के अनुसार, पासवर्ड सॉल्टेड MD5 प्रारूप में संग्रहीत थे; आधुनिक मानकों के अनुसार यह तरीका कमज़ोर है। इन फ़ील्ड का अलग-अलग मूल्यांकन किया गया। भुगतान कार्ड, बैंक खाते, आधिकारिक पहचान-पत्र, निजी संदेश, स्वास्थ्य रिकॉर्ड या अतिरिक्त प्रोफ़ाइल फ़ील्ड की पुष्टि नहीं हुई थी, इसलिए उन्हें डेटा श्रेणियों की सूची में नहीं जोड़ा गया।
फ़ोरम के उपयोगकर्ता नाम, जन्मतिथि और IP जानकारी को किसी ईमेल पते से जोड़ने पर अलग-अलग प्लेटफ़ॉर्म पर किसी व्यक्ति की पहचान को आपस में जोड़ना संभव हो सकता है। अकेले ईमेल पते से भी स्पैम और फ़िशिंग का जोखिम होता है, लेकिन उसे नाम, फ़ोन नंबर, पते, IP, जन्मतिथि या पेशेवर जानकारी के साथ जोड़ने से हमलावर के लिए व्यक्ति के अनुरूप संदेश तैयार करना आसान हो जाता है। इसलिए जोखिम का आकलन केवल रिकॉर्ड की संख्या के आधार पर नहीं, बल्कि इस आधार पर भी किया गया कि इन फ़ील्ड को एक साथ किस तरह इस्तेमाल किया जा सकता है।
सत्यापित दायरा और सीमाएँ
जुलाई 2016 के 3,26,714 फ़ोरम खातों के आधार पर दायरे की पुष्टि की गई। सत्यापित डेटा फ़ील्ड रखे गए, जबकि अपुष्ट फ़ील्ड हटा दिए गए। इससे उपयोगकर्ता को वास्तविक जोखिम कम करके बताए बिना और अनावश्यक रूप से भयभीत किए बिना उपलब्ध रिकॉर्ड की जानकारी दी जाती है।
यह रिकॉर्ड mac-forums.com डोमेन नाम तक सीमित है और Apple Inc. की प्रणालियों से जुड़ा नहीं है। दर्ज नाम से मिलती-जुलती अन्य घटनाओं को एक ही बड़ी घटना में नहीं मिलाया गया। डोमेन नाम, कंपनी का नाम और उद्योग संबंधी जानकारी को यथासंभव सीमित और सटीक संदर्भ में रखा गया; इससे एक ही सेंध को दोबारा जोड़ने या किसी सेंध को गलत संस्था से जोड़ने से बचा जाता है।
जोखिम में आने वाले उपयोगकर्ता समूह
जोखिम में वे उपयोगकर्ता हैं जिन्होंने Mac Forums पर खाता बनाया था, कोई तकनीकी सवाल पूछा था या Apple उपकरणों के बारे में सामुदायिक चर्चाओं में भाग लिया था। जिन उपयोगकर्ताओं के विवरण का मिलान होता है, उन्हें केवल संबंधित सेवा के खाते पर ही नहीं, बल्कि उन अन्य खातों पर भी ध्यान देना चाहिए जिनमें वही ईमेल पता, उपयोगकर्ता नाम या पासवर्ड पैटर्न इस्तेमाल किया गया है।
अलग-अलग फ़ोरम पर एक ही उपयोगकर्ता नाम इस्तेमाल करने से पहचान का मिलान किए जाने का जोखिम बढ़ता है, और एक ही पासवर्ड इस्तेमाल करने से खाते पर कब्ज़ा किए जाने का जोखिम बढ़ता है। कॉर्पोरेट ईमेल पते से पंजीकरण करने वालों के लिए जोखिम व्यक्तिगत खाते से आगे भी जा सकता है; हमलावर नाम, भूमिका, फ़ोन, पते, खरीदारी, गेम ID या पेशेवर प्रोफ़ाइल की जानकारी का इस्तेमाल करके अधिक विश्वसनीय लगने वाले संदेश भेज सकते हैं। इसलिए उपयोगकर्ताओं को विवरण के मिलान को केवल एक साइट तक सीमित समस्या नहीं मानना चाहिए।
तुरंत उठाए जाने वाले कदम
प्रभावित उपयोगकर्ताओं को अपना Mac Forums पासवर्ड बदलना चाहिए। साथ ही, उन ईमेल, Apple ID, गेमिंग, फ़ोरम और सोशल खातों के पासवर्ड भी बदलने चाहिए जिनमें वही पासवर्ड इस्तेमाल किया गया है। जिन रिकॉर्ड में पासवर्ड फ़ील्ड है, उनके लिए वही पासवर्ड इस्तेमाल करने वाले सभी खातों के पासवर्ड बदले जाने चाहिए। जिन रिकॉर्ड में पासवर्ड फ़ील्ड नहीं है, उनके लिए ईमेल, फ़ोन और फ़िशिंग के उद्देश्य से भेजी गई सूचनाओं के जोखिम पर ध्यान देना चाहिए। दोनों ही स्थितियों में ईमेल खाते को मज़बूत और अलग पासवर्ड से सुरक्षित किया जाना चाहिए।
संदेश में दिए गए लिंक पर क्लिक करने के बजाय संबंधित सेवा का पता स्वयं टाइप करना चाहिए या किसी भरोसेमंद पासवर्ड मैनेजर में दर्ज विवरण का इस्तेमाल करना चाहिए। फ़ोन पर मिले सत्यापन कोड, पासवर्ड रीसेट अनुरोध, शिपमेंट, नौकरी के प्रस्ताव, सहायता, सदस्यता या सुरक्षा संबंधी सूचनाओं जैसे संदेशों पर किसी स्वतंत्र माध्यम से पुष्टि किए बिना भरोसा नहीं करना चाहिए।
दीर्घकालीन सुरक्षा रणनीतियाँ
फ़ोरम और समुदाय के खातों को कम जोखिम वाला नहीं मानना चाहिए; हर फ़ोरम के लिए अलग पासवर्ड रखना चाहिए और प्रोफ़ाइल में सीमित जानकारी देनी चाहिए। पुराने खातों, इस्तेमाल न होने वाले फ़ोन और पते के फ़ील्ड, बार-बार इस्तेमाल होने वाले उपयोगकर्ता नामों और एक जैसे पासवर्ड पैटर्न की नियमित समीक्षा करके उन्हें हटाना या बदलना चाहिए। उपयोगकर्ताओं को हर सेवा के लिए अलग पासवर्ड इस्तेमाल करना चाहिए और जहाँ संभव हो, दो-चरणीय सत्यापन चालू करना चाहिए।
सेवा प्रदाताओं के लिए न्यूनतम डेटा रखना, पासवर्ड की मज़बूत सुरक्षा, एक्सेस लॉग की निगरानी, अनावश्यक प्रोफ़ाइल फ़ील्ड हटाना और सेंध के बाद उपयोगकर्ताओं को सूचित करना बुनियादी ज़रूरतें हैं। कई वर्षों से चल रहे फ़ोरम में पुराने पासवर्ड और प्रोफ़ाइल फ़ील्ड का नए हमलों में फिर से इस्तेमाल किया जा सकता है। ऐसी घटनाओं में दायरे की सटीक जानकारी देना तकनीकी सुधार जितना ही महत्वपूर्ण है; बढ़ा-चढ़ाकर दी गई या अधूरी जानकारी उपयोगकर्ता को गलत कदम उठाने की ओर ले जा सकती है।
रिकॉर्ड की जाँच और उपयोगकर्ता के कदम
उपयोगकर्ता को सबसे पहले अपने ईमेल पते से इस रिकॉर्ड में मिलान की जाँच करनी चाहिए। मिलान मिलने पर यह मानना चाहिए कि उपयोगकर्ता नाम, जन्मतिथि, IP और पासवर्ड फ़ील्ड जोखिम में हो सकते हैं। Apple खातों में भी जाँच करनी चाहिए कि कहीं वही पासवर्ड दोबारा तो इस्तेमाल नहीं किया गया है। मिलान न मिलने से यह संभावना पूरी तरह समाप्त नहीं होती कि पुराने पासवर्ड दोबारा इस्तेमाल किए गए हों या उसी सेवा से जुड़े दूसरे ईमेल पते इस्तेमाल हुए हों; इसलिए महत्वपूर्ण खातों की भी समीक्षा की जानी चाहिए।
यह रिकॉर्ड सत्यापित बना रहा और फ़ोरम के संदर्भ को Apple खातों से अलग रखने के लिए विवरण को पुनर्व्यवस्थित किया गया। इस संशोधन में डेटा फ़ील्ड के मानक श्रेणी-नाम अंग्रेज़ी में ही रखे गए, उपयोगकर्ता को दिखाई देने वाला विवरण तुर्की में मौलिक रूप से लिखा गया, अपुष्ट फ़ील्ड नहीं जोड़े गए और संवेदनशीलता का फ़्लैग केवल वहीं इस्तेमाल किया गया जहाँ जोखिम का संदर्भ उसका समर्थन करता था।
सत्यापन और संपादकीय प्रक्रिया
LeakData घटना के नाम, तारीख, प्रभावित रिकॉर्ड की संख्या और उजागर हुए डेटा के प्रकारों का सुलभ स्रोतों से मिलान करता है। असत्यापित जानकारी को तथ्य के रूप में प्रस्तुत नहीं किया जाता, और नए साक्ष्य उपलब्ध होने पर रिकॉर्ड अपडेट किए जाते हैं।
छूटी हुई या गलत जानकारी की रिपोर्ट करें