TigTag 2021 डेटा लीक

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

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

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

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

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

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