मैसेंजर का सर्वर हैक होने का मतलब ज़रूरी नहीं कि सभी संदेश पढ़ लिए जाएँ। नतीजा संग्रहीत डेटा, कुंजियों की जगह और हमलावर की पहुँच के स्तर पर निर्भर करता है। चैट का पाठ सही ढंग से एंड-टू-एंड एन्क्रिप्ट होने पर भी खाते की जानकारी, समय, समूह की सदस्यता और डिलीवरी का मार्ग संवेदनशील हो सकते हैं।
किसी घटना का मूल्यांकन करने के लिए पहले पूछें कि हमलावर को क्या मिला: डेटाबेस की एक प्रति, बुनियादी ढाँचे की कुंजियाँ, सक्रिय सर्वर या सॉफ़्टवेयर प्रकाशन प्रणाली? इन परिस्थितियों के परिणाम समान नहीं होते।
चुराया गया डेटाबेस और नियंत्रण में लिया गया सर्वर अलग हैं
जिस हमलावर के पास डेटाबेस की केवल पुरानी प्रति है, उसकी पहुँच उसमें दर्ज डेटा तक सीमित है। चलती सेवा पर नियंत्रण नए डेटा को दर्ज करने, सेशन चुराने, उत्तर बदलने या संपर्क की कुंजी बदलने की कोशिश का अवसर दे सकता है। सॉफ़्टवेयर वितरण श्रृंखला तक पहुँच एक अलग खतरा है: एंडपॉइंट पर दुर्भावनापूर्ण कोड एन्क्रिप्शन से पहले या डिक्रिप्शन के बाद पाठ देख सकता है।
इसलिए “डेटाबेस में संदेश के पाठ की कुंजी नहीं है” एक महत्वपूर्ण दावा है, लेकिन सभी तरह की सेंध का पूरा उत्तर नहीं है।
पाँच आर्किटेक्चर पैटर्न की तुलना
ये समझाने के लिए दिए गए पैटर्न हैं, पाँच उत्पादों की रैंकिंग नहीं। एक सेवा अलग-अलग सुविधाओं के लिए कई पैटर्न अपना सकती है।
| पैटर्न | डेटाबेस से उपलब्ध डेटा | महत्वपूर्ण सीमा |
|---|---|---|
| सादा पाठ वाले संदेश और पासवर्ड | सामग्री और क्रेडेंशियल सीधे पढ़े जा सकते हैं | दोनों तरह के डेटा के लिए उचित सुरक्षा का अभाव |
| हैश किए हुए पासवर्ड, सादा पाठ वाले संदेश | सामग्री पढ़ी जा सकती है; पासवर्ड के अनुमान जाँचे जा सकते हैं | पासवर्ड संग्रहण की गुणवत्ता चैट के पाठ की रक्षा नहीं करती |
| सर्वर की कुंजी से एन्क्रिप्ट की गई सामग्री | एन्क्रिप्टेड पाठ; उसे पढ़ना कुंजी तक पहुँच पर निर्भर है | कुंजी और डेटा का वास्तविक अलगाव महत्वपूर्ण है |
| E2EE चैट और प्रदाता की पहुँच वाला बैकअप | लाइव चैट सुरक्षित हो सकती है, लेकिन इतिहास की प्रति के लिए अलग खुलासा-मार्ग है | बैकअप की नीति और कुंजी जाँचनी चाहिए |
| E2EE चैट, एन्क्रिप्टेड रिकवरी और स्वतंत्र कुंजी | एन्क्रिप्टेड पाठ और परिचालन डेटा; सामग्री की सुरक्षा डिज़ाइन और कुंजी की रक्षा पर निर्भर है | डिवाइस, रिकवरी फ़्रेज़ और संपर्क की पहचान का प्रमाणीकरण अब भी महत्वपूर्ण हैं |
सर्वर डिस्क का एन्क्रिप्शन सीधे डिस्क की चोरी के विरुद्ध उपयोगी है। जब सक्रिय सेवा या डिक्रिप्शन की कुंजी भी हमलावर के पास हो, तो वही सुरक्षा मानकर नहीं चलना चाहिए। E2EE का लक्ष्य है कि बीच की सेवा के पास सुरक्षित सामग्री पढ़ने के लिए आवश्यक कुंजी न हो।
मेटाडेटा क्या दिखाता है?
मेटाडेटा बता सकता है कि किन खातों ने आपस में संपर्क किया, वे कब सक्रिय थे, किस समूह के सदस्य हैं और कितना डेटा भेजा गया। यह संदेश का पाठ नहीं है, लेकिन संबंधों के नेटवर्क या गतिविधि के पैटर्न को समझने में उपयोगी है।
Livara का सुरक्षा पृष्ठ रूटिंग, सदस्यता, समय, एन्क्रिप्टेड पाठ के आकार और डिलीवरी की स्थिति समेत परिचालन डेटा के संग्रहण और प्रसंस्करण को स्पष्ट करता है। निजी सामग्री की गोपनीयता का अर्थ पूरी गुमनामी या सर्वर पर किसी भी डेटा का न होना नहीं मानना चाहिए।
SRP खाते के डेटा को अनुमान लगाने के जोखिम से मुक्त नहीं करता
SRP सीधे पासवर्ड भेजे बिना यह साबित करने का तरीका है कि आप उसे जानते हैं। सर्वर फिर भी verifier नाम का सत्यापन डेटा रखता है। RFC 5054 का सुरक्षा अनुभाग समझाता है कि verifier की चोरी पासवर्ड का अनुमान लगाने के लिए शब्दकोश हमला संभव बना सकती है।
इसलिए “पासवर्ड नेटवर्क पर नहीं भेजा जाता” और “चुराने के लिए पासवर्ड से जुड़ा कोई डेटा नहीं है” अलग बातें हैं। अनूठा और मज़बूत पासवर्ड, डिवाइस की सुरक्षा और घटना पर उचित प्रतिक्रिया अब भी आवश्यक हैं। SRP सामग्री के एन्क्रिप्शन या लॉगिन सेशन की सुरक्षा का विकल्प भी नहीं है।
Livara के बारे में कौन-सी सीमाएँ बताई गई हैं?
Livara का सुरक्षा दस्तावेज़ सीधे संदेशों के लिए LVR1 और सुरक्षित समूहों के लिए LGS1 का वर्णन करता है। समूह की सुरक्षा उसकी वास्तविक स्थिति पर निर्भर है; असंगत पुराने समूह को E2EE का लेबल नहीं मिलना चाहिए। सार्वजनिक चैनल गोपनीयता की इस सीमा के बाहर हैं।
यही दस्तावेज़ v7 रिकवरी को एन्क्रिप्टेड पहचान-पैकेज बताता है, जिसे अपलोड से पहले सुरक्षित किया जाता है। यह प्रक्रिया क्रिप्टोग्राफ़िक पहचान वापस लाती है, चैट इतिहास नहीं। रिकवरी फ़्रेज़ या कुंजियाँ रखने वाले डिवाइस का उजागर होना केवल डेटाबेस की चोरी से अलग परिस्थिति है।
ये उत्पाद के प्रकाशित विवरण हैं, इस लेख द्वारा किए गए स्वतंत्र ऑडिट के निष्कर्ष नहीं। केवल AES या ML-KEM का उल्लेख भी सही कुंजी प्रबंधन और ऐप के सही कार्यान्वयन को साबित नहीं करता।
घटना की घोषणा पर कौन-से सवाल पूछें?
- कौन-सी समयावधि और कौन-से सिस्टम प्रभावित हुए? “उपयोगकर्ताओं की जानकारी” जैसा अस्पष्ट शब्द पर्याप्त नहीं है।
- क्या सादा पाठ, फ़ाइलें, कुंजियाँ, verifier, लॉगिन सेशन उपलब्ध थे या केवल एन्क्रिप्टेड पाठ?
- क्या हमलावर सेवा या उपयोगकर्ताओं तक पहुँचने वाले सॉफ़्टवेयर को बदल सकता था?
- आधिकारिक रास्ते से कौन-से कदम आवश्यक हैं: सेशन से लॉगआउट, पासवर्ड बदलना, अपडेट या संपर्क की पहचान जाँचना?
- क्या सुझाई गई रिकवरी स्थानीय इतिहास मिटा सकती है? ऐप हटाने से पहले सीमाएँ पढ़ें।
“खाते का तत्काल सत्यापन” करने के लिए अनजान संदेश के लिंक का उपयोग न करें। आधिकारिक पता स्वतंत्र रूप से खोलकर सूचना पढ़ें। Livara का थ्रेट मॉडल सामान्य सीमाएँ समझने में उपयोगी है; वास्तविक घटना का दायरा उसी घटना के सबूतों से तय होना चाहिए।
