RegMe: डेटा उजागर होने का कथित मामला

RegMe पंजीकरण में ईमेल पता, पूरा नाम, फ़ोन नंबर और पासवर्ड हैश जैसे फ़ील्ड एक साथ सूचीबद्ध होने से कई माध्यमों से हमले होने का जोखिम बढ़ता है। ईमेल पते का इस्तेमाल फ़िशिंग के लिए, फ़ोन नंबर का इस्तेमाल SMS या कॉल के ज़रिए धोखाधड़ी के लिए और नाम संबंधी जानकारी का इस्तेमाल संदेशों को व्यक्तिगत बनाने के लिए किया जा सकता है। पासवर्ड हैश, पासवर्ड का सादे टेक्स्ट वाला रूप नहीं है। फिर भी, यदि कमज़ोर पासवर्ड या पुरानी हैश विधि का इस्तेमाल किया गया हो, तो उसे क्रैक करने के प्रयास हो सकते हैं। आयोजन प्लेटफ़ॉर्म से जुड़े संदर्भ के कारण नकली निमंत्रण, पंजीकरण की पुष्टि, टिकट नवीनीकरण, बैठक के लिंक या भुगतान की पुष्टि जैसे संदेश अधिक भरोसेमंद लग सकते हैं।

यह रिकॉर्ड खुले डेटा की सूचियों में लगभग इसी आकार और समान फ़ील्ड के साथ दिखाई देता है। हालाँकि, कंपनी ने इस घटना के बारे में कोई ऐसी सूचना प्रकाशित नहीं की है जिसका सत्यापन किया जा सके, इसलिए LeakData पर सत्यापन का संकेत बंद रखा गया है। इसका दायरा पंक्तियों की अनुमानित संख्या को दर्शाता है; इसे अलग-अलग व्यक्तियों की संख्या नहीं समझना चाहिए। हर पंक्ति में सभी फ़ील्ड मौजूद हों, यह ज़रूरी नहीं है। गतिविधियों की सामग्री, भुगतान संबंधी जानकारी, पहचान के दस्तावेज़ या निजी संदेश इस रिकॉर्ड के सत्यापित फ़ील्ड के रूप में नहीं जोड़े गए हैं। इस डेटासेट की पुष्टि सीमित होने के बावजूद, उपयोगकर्ता को सुरक्षा संबंधी कदम ईमेल, फ़ोन और पासवर्ड के एक साथ मौजूद होने से पैदा होने वाले व्यावहारिक जोखिम के आधार पर तय करने चाहिए।

जोखिम में वे उपयोगकर्ता हो सकते हैं जिन्होंने RegMe के ज़रिए किसी आयोजन के लिए पंजीकरण किया हो या किसी बैठक अथवा सम्मेलन में भाग लेने के लिए अपना फ़ोन नंबर और ईमेल साझा किया हो। कॉर्पोरेट आयोजनों में भाग लेने वाले, कंपनी का ईमेल पता इस्तेमाल करने वाले और काम के अलग-अलग टूल में एक ही पासवर्ड दोहराने वाले उपयोगकर्ताओं को अधिक जोखिम होता है। हमलावर आगामी आयोजनों, बैठक के बदले हुए लिंक, धनवापसी, भागीदारी प्रमाणपत्र या पंजीकरण के सत्यापन के बहाने लिंक भेज सकते हैं। जिन उपयोगकर्ताओं के फ़ोन नंबर मौजूद हैं, उन्हें SMS के ज़रिए एक बार इस्तेमाल होने वाला कोड माँगने या सहायता के नाम पर नकली कॉल करने जैसे तरीकों से भी निशाना बनाया जा सकता है। इसलिए काम से जुड़े और निजी खातों का आकलन एक साथ करना चाहिए।

जिन उपयोगकर्ताओं के खातों का इस रिकॉर्ड से मेल मिलता है, उन्हें जाँचना चाहिए कि RegMe खाते पर उन्होंने जो पासवर्ड इस्तेमाल किया होगा, क्या वही अन्य सेवाओं पर भी इस्तेमाल हो रहा है। यदि काम के ईमेल, कैलेंडर, वीडियो कॉन्फ़्रेंसिंग, CRM, सोशल मीडिया या निजी ईमेल खातों में वही पासवर्ड या उसके मिलते-जुलते रूप इस्तेमाल हो रहे हों, तो उन्हें बदलना चाहिए और बहु-कारक प्रमाणीकरण चालू करना चाहिए। फ़ोन या SMS के ज़रिए मिले आयोजन संबंधी लिंक सीधे नहीं खोलने चाहिए; उनकी पुष्टि आयोजनकर्ता के आधिकारिक माध्यम से करनी चाहिए। कैलेंडर के निमंत्रणों में आए अप्रत्याशित लिंक और संलग्न फ़ाइलों की सावधानी से जाँच करनी चाहिए। कॉर्पोरेट उपयोगकर्ताओं को अपने ईमेल पते का मेल मिलने की जानकारी अपनी सूचना सुरक्षा टीम को देनी चाहिए।

आयोजन प्लेटफ़ॉर्म को अनावश्यक फ़ोन और पासवर्ड डेटा लंबे समय तक नहीं रखना चाहिए, पासवर्ड हैश करने की आधुनिक विधियाँ अपनानी चाहिए और पुराने आयोजन रिकॉर्ड की संख्या नियमित रूप से कम करनी चाहिए। उपयोगकर्ताओं को काम से जुड़े और निजी आयोजन खातों के लिए अलग-अलग पासवर्ड रखने चाहिए। यदि संभव हो, तो आयोजनों के पंजीकरण के लिए अलग ईमेल पता इस्तेमाल करना चाहिए। संगठनों को जागरूकता बढ़ानी चाहिए, ताकि कर्मचारी आयोजन प्लेटफ़ॉर्म पर वही पासवर्ड इस्तेमाल न करें जो वे अपने काम के खातों में इस्तेमाल करते हैं। आयोजन संबंधी संदेशों में छोटे लिंक और अप्रत्याशित संलग्न फ़ाइलों को जोखिम भरा मानना चाहिए। लंबे समय में सबसे अच्छा बचाव है एक ही पासवर्ड का दोबारा इस्तेमाल बंद करना और फ़ोन के ज़रिए आने वाले अनुरोधों की पुष्टि किसी स्वतंत्र माध्यम से करना।

LeakData पर जाँच करने से आपको यह देखने में मदद मिलती है कि आपका ईमेल पता RegMe रिकॉर्ड से मेल खाता है या नहीं। यदि मेल मिलता है, तो सबसे पहले उन खातों के पासवर्ड बदलें जिनमें आप वही पासवर्ड इस्तेमाल करते हैं और अपने ईमेल तथा काम के खातों पर अतिरिक्त सत्यापन चालू करें। यह ध्यान रखते हुए कि आपका फ़ोन नंबर भी शामिल हो सकता है, SMS लिंक, गतिविधियों की नकली सूचनाओं और बैठक के निमंत्रणों की सावधानी से जाँच करें। मेल न मिलने पर, किसी अलग ईमेल पते से बनाए गए पुराने रिकॉर्ड जाँच के दायरे से बाहर रह सकते हैं। भले ही इस रिकॉर्ड की पुष्टि किसी आधिकारिक सूचना से न हुई हो, गतिविधियों से जुड़े संदर्भ और फ़ोन के उपयोग को देखते हुए सोशल इंजीनियरिंग के जोखिम पर नज़र रखनी चाहिए।