SHARE THE PERSPECTIVE

कोई संदेश ऐप ताले का चिह्न दिखा सकता है, खुद को निजी कह सकता है और फिर भी महत्वपूर्ण सवालों को अनुत्तरित छोड़ सकता है।

कौन-सी बातचीत एन्क्रिप्टेड हैं? क्या अटैचमेंट सुरक्षित हैं? कुंजियाँ कहाँ रखी जाती हैं? सर्वर कौन-सी जानकारी रखता है? उपकरण खो जाने पर क्या होता है? क्या एन्क्रिप्शन कुंजियाँ बिना चेतावनी बदल सकती हैं?

ये विवरण उपयोगी सुरक्षा उपायों और अब भी अनुपलब्ध प्रमाणों, दोनों को पहचानने में मदद करते हैं। कोई जाँच-सूची अकेले किसी उत्पाद को सुरक्षित प्रमाणित नहीं करती।

यह मार्गदर्शिका 12 व्यावहारिक सवाल देती है जिन्हें व्यक्तिगत बातचीत, गोपनीय फ़ाइलें या संवेदनशील काम किसी एन्क्रिप्टेड संदेश ऐप को सौंपने से पहले पूछना चाहिए।

सुरक्षित संदेश ऐप क्या है?

सुरक्षित संदेश ऐप एक संचार सेवा है जिसे बातचीत को अनधिकृत पहुँच, बीच में पकड़े जाने, खाते पर कब्ज़े और अनजाने डेटा खुलासे से बचाने के लिए बनाया जाता है।

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

अत्यधिक निजी बातचीत के लिए उसे एंड-टू-एंड एन्क्रिप्शन भी देना चाहिए।

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

हालाँकि, एन्क्रिप्शन संदेश सुरक्षा का सिर्फ एक हिस्सा है।

संपूर्ण मूल्यांकन में इन बातों पर भी विचार करना चाहिए:

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

अधिक गहन परिचय के लिए “एंड-टू-एंड एन्क्रिप्शन की व्याख्या” पढ़ें।

केवल “एन्क्रिप्टेड” शब्द पर्याप्त क्यों नहीं है

लगभग हर आधुनिक संदेश सेवा HTTPS, TLS या किसी अन्य सुरक्षित परिवहन माध्यम से नेटवर्क ट्रैफ़िक एन्क्रिप्ट करती है।

यह सुरक्षा महत्वपूर्ण है, लेकिन इसका अर्थ आवश्यक रूप से यह नहीं कि बातचीत एंड-टू-एंड एन्क्रिप्टेड है।

परिवहन एन्क्रिप्शन में डेटा आपके उपकरण और सेवा के बीच जाते समय सुरक्षित रहता है। दूसरी सुरक्षित कनेक्शन से पहुँचाने से पहले सेवा को पढ़ने योग्य सामग्री फिर भी मिल सकती है।

E2EE में समर्थित संदेश सामग्री संदेश सेवा तक पहुँचने से पहले ही प्रतिभागियों के लिए एन्क्रिप्ट हो जाती है।

यह अंतर प्रभावित करता है कि तकनीकी रूप से संदेश सामग्री तक कौन पहुँच सकता है।

इसीलिए सामान्य “एन्क्रिप्टेड” लेबल स्वीकार करने के बजाय सटीक सवाल पूछने चाहिए।

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

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

1. कौन-सी बातचीत एंड-टू-एंड एन्क्रिप्टेड हैं?

यह न मानें कि एन्क्रिप्शन का एक बयान ऐप के हर हिस्से पर लागू होता है।

संदेश सेवा इनके लिए अलग-अलग सुरक्षा दे सकती है:

  • दो लोगों के बीच सीधी बातचीत
  • निजी समूह
  • सार्वजनिक समूह
  • प्रसारण चैनल
  • वॉइस और वीडियो कॉल
  • स्टोरी या अस्थायी पोस्ट
  • बॉट और स्वचालित खाते
  • सिंक किया गया बातचीत इतिहास

प्रदाता से सटीक सीमा बताने को कहें।

एक ठोस जवाब ऐसा होता है:

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

एक कमज़ोर जवाब ऐसा होता है:

आपका संचार सैन्य-स्तर के एन्क्रिप्शन से सुरक्षित है।

पहला जवाब ऐसी जानकारी देता है जिसका आप मूल्यांकन कर सकते हैं। दूसरा संरक्षित सामग्री या ख़तरे के मॉडल को परिभाषित किए बिना प्रभावशाली भाषा इस्तेमाल करता है।

2. क्या फ़ोटो, वीडियो और अटैचमेंट भी एन्क्रिप्टेड हैं?

कोई ऐप टेक्स्ट एन्क्रिप्ट कर सकता है, जबकि अपलोड किए गए मीडिया को अलग प्रणाली से संभालता हो।

इससे एक महत्वपूर्ण सवाल उठता है: क्या फ़ोटो अपलोड से पहले क्लाइंट पर एन्क्रिप्ट होती है, या केवल सर्वर अनुमतियों और परिवहन एन्क्रिप्शन से सुरक्षित होती है?

इनके बारे में पूछें:

  • फ़ोटो और वीडियो
  • दस्तावेज़
  • वॉइस संदेश
  • लिंक पूर्वावलोकन
  • थंबनेल
  • अस्थायी अपलोड फ़ाइलें
  • कैश किया गया मीडिया
  • डाउनलोड की अनुमति

मीडिया की सुरक्षा का अलग विवरण होना चाहिए, उसे “संदेशों” के व्यापक दावे में छिपाना नहीं चाहिए।

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

3. एन्क्रिप्शन कुंजियाँ कहाँ बनती और रखी जाती हैं?

एन्क्रिप्शन उतना ही भरोसेमंद है जितना उसका कुंजी-प्रबंधन।

क्लाइंट-पक्षीय E2EE के लिए निजी-कुंजी सामग्री प्रतिभागियों के उपकरणों के नियंत्रण में रहनी चाहिए। सार्वजनिक कुंजियाँ साझा की जा सकती हैं ताकि संपर्क एन्क्रिप्टेड संचार स्थापित कर सकें, लेकिन निजी कुंजियों को अधिक मज़बूत सुरक्षा चाहिए।

इन सवालों के स्पष्ट जवाब खोजें:

  • क्या निजी कुंजी उपकरण पर बनती है?
  • क्या कभी उसे बिना एन्क्रिप्शन अपलोड किया जाता है?
  • क्या प्रदाता उसे निकाल सकता है या बदल सकता है?
  • क्या कोई दूसरा साइन-इन किया हुआ उपकरण उसे अपने-आप प्राप्त कर सकता है?
  • क्या स्थानीय कुंजी भंडारण सुरक्षित है?
  • कुंजी रीसेट करने के बाद क्या होता है?
  • क्या ऐप दोबारा इंस्टॉल करने से नई पहचान कुंजी बनती है?

दस्तावेज़ों को कार्यान्वयन का हर विवरण बताने की ज़रूरत नहीं। लेकिन उन्हें निजी कुंजियों का स्वामित्व और जीवनचक्र समझाना चाहिए।

4. क्या संपर्क एक-दूसरे की कुंजियों की पुष्टि कर सकते हैं?

एंड-टू-एंड एन्क्रिप्शन बातचीत की रक्षा तभी करता है जब एन्क्रिप्शन कुंजियाँ इच्छित प्रतिभागियों की हों।

कई सुरक्षित संदेश प्रणालियाँ सार्वजनिक कुंजी को फ़िंगरप्रिंट, सुरक्षा नंबर, QR कोड या किसी अन्य सत्यापन मान से दर्शाती हैं।

दो संपर्क इस मान की तुलना किसी विश्वसनीय माध्यम से कर सकते हैं, जैसे:

  • आमने-सामने मुलाकात
  • सत्यापित वॉइस कॉल
  • पहले से प्रमाणित खाता
  • विश्वसनीय कंपनी निर्देशिका

कुंजी सत्यापन से अतिरिक्त भरोसा मिलता है कि अपेक्षित कुंजियाँ इस्तेमाल हो रही हैं; यह अकेले किसी व्यक्ति की पहचान का प्रमाण नहीं है। कुछ उत्पाद कुंजी-पारदर्शिता जाँच भी देते हैं, जैसे Signal का स्वचालित सत्यापन। हर उत्पाद से केवल मैन्युअल प्रक्रिया की माँग करने के बजाय समर्थित खातों और संस्करणों की शर्तें देखें।

यह भी पूछें कि फ़िंगरप्रिंट बदलने पर क्या होता है।

बदली हुई कुंजी का सामान्य कारण हो सकता है, जैसे रीसेट, उपकरण बदलना या पुनर्प्राप्ति प्रक्रिया। लेकिन बदलाव दिखना चाहिए। चुपचाप प्रतिस्थापन होने से पहचान-कुंजी का अप्रत्याशित बदलाव पकड़ना कठिन होता है।

5. सेवा कौन-सा मेटाडेटा रखती है?

संदेश सामग्री और संदेश मेटाडेटा अलग श्रेणियाँ हैं।

ऐसा हो सकता है कि सेवा E2EE संदेश का मुख्य पाठ न पढ़ सके, फिर भी बातचीत पहुँचाने, सिंक करने और दिखाने के लिए ज़रूरी जानकारी संसाधित करती हो।

प्रणाली के अनुसार इसमें शामिल हो सकते हैं:

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

परिचालन मेटाडेटा का मौजूद होना सेवा को अपने-आप असुरक्षित नहीं बनाता।

महत्वपूर्ण सवाल हैं:

  • क्या एकत्र होता है?
  • इसकी ज़रूरत क्यों है?
  • कितने समय तक रखा जाता है?
  • उस तक कौन पहुँच सकता है?
  • क्या उपयोगकर्ता उसे निर्यात या मिटा सकता है?
  • क्या उसे विज्ञापन या असंबंधित प्रोफ़ाइल बनाने के लिए इस्तेमाल किया जाता है?

सावधान रहें जब कोई प्रदाता यह परिभाषित किए बिना “कोई मेटाडेटा नहीं” रखने का दावा करे कि वह मेटाडेटा किसे मानता है।

6. आपका खाता कैसे प्रमाणित होता है?

मज़बूत संदेश एन्क्रिप्शन कमज़ोर खाता सुरक्षा की भरपाई नहीं करता।

खाते पर कब्ज़ा करने वाला हमलावर उपयोगकर्ता का रूप धर सकता है, नई कुंजी दर्ज कर सकता है, सर्वर द्वारा पढ़ी जा सकने वाली सामग्री तक पहुँच सकता है या पुनर्प्राप्ति में दखल दे सकता है।

मूल्यांकन करें कि सेवा ये सुरक्षा उपाय देती है या नहीं:

  • सुरक्षित पासवर्ड प्रबंधन
  • अनुरोधों की दर सीमित करना
  • सत्र निरस्त करना
  • स्पष्ट उपकरण या सत्र प्रबंधन
  • पकड़े गए लॉगिन विवरण को दोबारा प्रस्तुत करने वाले हमलों से सुरक्षा
  • सुरक्षित पासवर्ड-रीसेट प्रक्रियाएँ
  • जहाँ उचित हो बहु-कारक प्रमाणीकरण
  • खाते में महत्वपूर्ण बदलावों की सूचनाएँ

खाता प्रमाणीकरण और संदेश एन्क्रिप्शन में अंतर भी करें।

साइन-इन साबित करता है कि किसी के पास खाते का लॉगिन विवरण है। यह आवश्यक रूप से साबित नहीं करता कि उपकरण के पास मूल निजी एन्क्रिप्शन कुंजी है।

7. एन्क्रिप्टेड पुनर्प्राप्ति कैसे काम करती है?

पुनर्प्राप्ति निजी संदेश सेवाओं के सबसे कठिन संतुलनों में से एक बनाती है।

उपयोगकर्ता स्वाभाविक रूप से उपकरण बदलने के बाद बातचीत इतिहास चाहते हैं। लेकिन यदि प्रदाता हर निजी कुंजी चुपचाप बहाल कर सकता है, तो उसके पास उपयोगकर्ताओं की अपेक्षा से अधिक डिक्रिप्शन क्षमता हो सकती है।

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

पूछें:

  • क्या बैकअप अपलोड से पहले एन्क्रिप्ट होता है?
  • क्या उसे बहाल करने के लिए खाता पासवर्ड पर्याप्त है?
  • क्या प्रदाता गुप्त पुनर्प्राप्ति जानकारी जानता है?
  • क्या सहायता कर्मचारी उसे रीसेट कर सकते हैं?
  • गुप्त जानकारी खोने पर क्या होता है?
  • क्या बहाली वही सार्वजनिक-कुंजी फ़िंगरप्रिंट बनाए रखती है?
  • क्या पुनर्प्राप्ति बंद की जा सकती है?

विश्वसनीय जवाब में एक असहज सीमा शामिल हो सकती है: निजी कुंजी और गुप्त पुनर्प्राप्ति जानकारी, दोनों खोने पर पुरानी एन्क्रिप्टेड सामग्री वापस पाना असंभव हो सकता है।

यह परिणाम उत्पाद की कमी के बजाय वास्तविक सुरक्षा सीमा का प्रमाण हो सकता है।

8. कनेक्शन टूटने पर क्या होता है?

सुरक्षा और विश्वसनीयता को साथ काम करना चाहिए।

मोबाइल कनेक्शन गायब होते हैं। ब्राउज़र निष्क्रिय हो जाते हैं। उपकरण नेटवर्क बदलते हैं। अच्छे डिज़ाइन वाला मैसेंजर अस्थायी वियोग को संदेश दोहराए बिना, क्रम खोए बिना या एन्क्रिप्शन कमज़ोर किए बिना संभाले।

ऐसा ऑफ़लाइन और सिंक्रोनाइज़ेशन मॉडल खोजें जो:

  1. बाहर भेजी जाने वाली कार्रवाई स्थानीय रूप से तैयार करे।
  2. उसे स्थिर पहचानकर्ता दे।
  3. दोबारा जुड़ने पर सुरक्षित रूप से पुनः प्रयास करे।
  4. दोहरी बार भेजने से बचे।
  5. सर्वर की पुष्टि के साथ स्थिति का मिलान करे।
  6. ऑफ़लाइन रहते हुए छूटे बदलाव प्राप्त करे।

अलग से पूछें कि संदेश के इंतज़ार करते समय ऐप नेटवर्क पेलोड और स्थानीय आउटबॉक्स की रक्षा कैसे करता है। E2EE अपने-आप साबित नहीं करता कि स्थानीय कतार भंडारण के दौरान एन्क्रिप्टेड है।

नेटवर्क पुनः प्रयास के लिए डिलीवरी सेवा को ऐसे संदेश की खुली प्रति देना आवश्यक नहीं होना चाहिए जो अन्यथा एंड-टू-एंड एन्क्रिप्टेड है।

9. अपलोड और संग्रहीत ऑब्जेक्ट की पहुँच कैसे अधिकृत होती है?

मीडिया सुरक्षा में एन्क्रिप्शन से अधिक बातें शामिल हैं।

सेवा अवतार, संदेश अटैचमेंट, वॉलपेपर, स्टोरी, अस्थायी अपलोड और बनाए गए थंबनेल संभाल सकती है। हर ऑब्जेक्ट को पहुँच नीति चाहिए।

जाँचें कि ऐप:

  • निजी मीडिया पाने के लिए प्रमाणीकरण माँगता है
  • सत्यापित करता है कि अनुरोध करने वाला खाता संबंधित बातचीत का सदस्य है
  • सार्वजनिक संसाधनों को निजी संदेश ऑब्जेक्ट से अलग रखता है
  • बिना संलग्न हुए अपलोड साफ़ करता है
  • समय समाप्त हो चुके अस्थायी ऑब्जेक्ट हटाता है
  • अलग-अलग खातों के बीच कैश साझा होने से रोकता है
  • अप्रत्याशित पहचानकर्ता इस्तेमाल करता है, लेकिन अनुमान न लग पाने को ही अनुमति नहीं मानता

निजी खुली फ़ाइल केवल इसलिए पढ़ने योग्य नहीं हो जानी चाहिए कि किसी ने उसका URL अनुमान से पा लिया। एन्क्रिप्टेड ऑब्जेक्ट के लिए देखें कि कुंजियाँ और पहुँच-अधिकार कैसे बाँटे और वापस लिए जाते हैं। OWASP का प्राधिकरण मार्गदर्शन स्थिर संसाधनों सहित हर जगह पहुँच निर्णय समान रूप से लागू करने की सिफ़ारिश करता है; अकेला अप्रत्याशित पहचानकर्ता संपूर्ण अनुमति नीति नहीं है।

10. क्या समूह चैट अलग ढंग से सुरक्षित होती हैं?

समूह एन्क्रिप्शन और सदस्यता नियंत्रण सीधे चैट एन्क्रिप्शन से अलग सवाल उठाते हैं।

सदस्यता बदलना, कई उपकरण, संदेश इतिहास, प्रशासक भूमिकाएँ, निमंत्रण, सदस्य हटाना और कुंजी रोटेशन सभी अतिरिक्त डिज़ाइन आवश्यकताएँ पैदा करते हैं।

कुछ सेवाएँ सीधी और समूह, दोनों चैट के लिए E2EE देती हैं। अन्य केवल सीधी बातचीत में E2EE देती हैं और समूहों को TLS, प्रमाणित भंडारण और सर्वर-पक्षीय पहुँच नियंत्रण से सुरक्षित करती हैं।

दूसरा मॉडल भी सार्थक सुरक्षा दे सकता है, लेकिन उसकी भरोसे की सीमा अलग है।

पूछें कि क्या सर्वर समूह सामग्री संसाधित कर सकता है और क्या सुरक्षा बदलती है जब:

  • कोई सदस्य जुड़ता है
  • कोई सदस्य निकलता है
  • प्रशासक किसी को हटाता है
  • संदेश संपादित होता है
  • इतिहास नए उपकरण पर सिंक होता है
  • बॉट या एकीकरण समूह में आता है

कभी यह न मानें कि एक प्रकार की बातचीत में दिख रहा ताला अपने-आप सभी दूसरे प्रकारों पर लागू होता है।

11. उपयोगकर्ता के पास कौन-से गोपनीयता नियंत्रण हैं?

गोपनीयता का संबंध सेवा तक जानकारी पहुँचने के बाद के नियंत्रण से भी है।

खाते और बातचीत के ऐसे व्यावहारिक नियंत्रण खोजें:

  • खाते का डेटा निर्यात करना
  • खाता मिटाना
  • सत्र निरस्त करना
  • स्थानीय या सिंक किया गया इतिहास साफ़ करना
  • जहाँ अनुमति हो भेजे गए संदेश मिटाना
  • पढ़े जाने की रसीदें प्रबंधित करना
  • प्रोफ़ाइल की दृश्यता नियंत्रित करना
  • अनचाहे संपर्क रोकना
  • सूचना पूर्वावलोकन प्रबंधित करना
  • कुंजी बैकअप बंद करना या मिटाना

प्रदाता को बताना चाहिए कि मिटाने से केवल आपकी प्रति हटती है, हर प्रतिभागी की प्रति या स्वयं सर्वर रिकॉर्ड।

प्राप्तकर्ता संदेश पहले ही डाउनलोड, कॉपी, अग्रेषित या फ़ोटो में कैद कर चुका हो सकता है। मिटाने की कोई सुविधा हर अंतिम उपकरण से उसे हटाने की गारंटी नहीं दे सकती।

12. क्या सुरक्षा के दावे विशिष्ट और सत्यापनीय हैं?

सबसे मज़बूत सुरक्षा दस्तावेज़ सीमाएँ परिभाषित करते हैं।

इन विषयों पर विशिष्ट बयान खोजें:

  • एल्गोरिदम और कुंजी आकार
  • क्लाइंट-पक्षीय बनाम सर्वर-पक्षीय कार्य
  • E2EE के अंतर्गत आने वाली बातचीत के प्रकार
  • मीडिया एन्क्रिप्शन
  • संग्रहीत जानकारी
  • प्रमाणीकरण
  • पुनर्प्राप्ति
  • कुंजी बदलाव
  • पहुँच नियंत्रण
  • ज्ञात सीमाएँ
  • दस्तावेज़ आख़िरी बार अपडेट होने की तारीख

इन अस्पष्ट वाक्यांशों को सावधानी से लें:

  • अटूट एन्क्रिप्शन
  • पूर्ण गोपनीयता
  • सैन्य-स्तर की सुरक्षा
  • पूरी तरह गुमनाम
  • शून्य मेटाडेटा
  • हैक करना असंभव
  • भविष्य के हर ख़तरे से सुरक्षित एन्क्रिप्शन

किसी जटिल संचार प्रणाली का मूल्यांकन केवल नारे से नहीं करना चाहिए।

स्वतंत्र ऑडिट, सार्वजनिक तकनीकी दस्तावेज़, पुनरुत्पादनीय क्लाइंट, पेशेवर समीक्षाएँ और स्पष्ट दायरे वाली सुरक्षा रिपोर्ट अतिरिक्त भरोसा दे सकती हैं। वे सभी समान स्तर के प्रमाण नहीं देतीं, लेकिन बिना आधार के अतिशयोक्तिपूर्ण दावों से अधिक उपयोगी हैं।

सुरक्षित संदेश: मज़बूत संकेत और चेतावनी संकेत

मज़बूत संकेत चेतावनी संकेत
प्रदाता बताता है कि कौन-सी बातचीत E2EE है हर सुविधा को बस “एन्क्रिप्टेड” बताया जाता है
निजी-कुंजी स्वामित्व समझाया जाता है कुंजी प्रबंधन की कभी चर्चा नहीं होती
कुंजी बदलाव दिखाई देते हैं कुंजियाँ चुपचाप बदल सकती हैं
पुनर्प्राप्ति सीमाएँ दस्तावेज़ित हैं सहायता सब कुछ बहाल कर सकती है, लेकिन तरीका नहीं बताती
मेटाडेटा श्रेणियाँ सूचीबद्ध हैं प्रदाता बिना परिभाषा “शून्य मेटाडेटा” कहता है
मीडिया सुरक्षा अलग बताई जाती है केवल टेक्स्ट संदेशों का उल्लेख है
समूहों की भरोसे की सीमा परिभाषित है सीधी चैट के दावों को समूहों पर भी लागू माना जाता है
सुरक्षा पृष्ठों में वर्तमान कार्यान्वयन विवरण हैं मार्केटिंग भाषा तकनीकी दस्तावेज़ों से टकराती है
सीमाएँ स्पष्ट कही जाती हैं सेवा पूर्ण या अटूट सुरक्षा का दावा करती है

Livara के सार्वजनिक दावों पर जाँच-सूची लागू करना

Livara का सुरक्षा पृष्ठ उत्पाद दस्तावेज़ देता है, स्वतंत्र प्रमाणन नहीं। उसकी वर्तमान सीमाएँ इनमें अंतर करती हैं:

  • सीधे संदेश: LVR1 समर्थित सामग्री के लिए हाइब्रिड P-256 और ML-KEM-768 कुंजी समझौता तथा प्रमाणित एन्क्रिप्शन इस्तेमाल करता है।
  • संगत निजी समूह: LGS1 प्रेषक-कुंजी सुरक्षा; सदस्यता और भूमिकाएँ सर्वर-अधिकार की अलग सीमा बनी रहती हैं। पुराने असंगत समूहों को अपने-आप E2EE का लेबल नहीं मिलना चाहिए।
  • सार्वजनिक चैनल: सर्वर द्वारा पढ़ी जा सकने वाली सामग्री, E2EE नहीं।
  • पुनर्प्राप्ति: पहचान सामग्री अपलोड से पहले एन्क्रिप्शन से सील होती है; उसे बहाल करना चैट इतिहास बहाल करना नहीं है।
  • मेटाडेटा और उपकरण: रूटिंग रिकॉर्ड और जिन अंतिम उपकरणों की सुरक्षा भंग हो चुकी है, वे सामग्री एन्क्रिप्शन के वादे से बाहर रहते हैं।

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

60 सेकंड की सुरक्षित संदेश जाँच-सूची

खाता बनाने से पहले देखें कि क्या आप हर सवाल का जवाब दे सकते हैं:

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

अनुत्तरित बिंदुओं को “अज्ञात” लिखें, अपने-आप “सुरक्षित” या “असुरक्षित” नहीं। प्रदाता को हर प्रतिस्पर्धी जैसा ही ढाँचा अपनाना आवश्यक नहीं।

लेकिन उसे इतने सटीक जवाब देने चाहिए कि उपयोगकर्ता समझ सकें कि वे किस पर भरोसा कर रहे हैं।

सबसे सुरक्षित विकल्प आपके ख़तरे के मॉडल पर निर्भर करता है

कोई सार्वभौमिक संदेश ऐप हर व्यक्ति और परिस्थिति के लिए अपने-आप सर्वश्रेष्ठ नहीं है।

परिवार समूह, कार्यस्थल, पत्रकार और स्रोत, स्वास्थ्य सेवा टीम और सार्वजनिक समुदाय को इनका अलग-अलग मिश्रण चाहिए हो सकता है:

  • गोपनीयता
  • पहचान सत्यापन
  • गुमनामी
  • समूह प्रशासन
  • संदेश रखना
  • नियामक अनुपालन
  • पुनर्प्राप्ति
  • कई उपकरणों का समर्थन
  • खुला स्रोत कोड
  • स्वतंत्र ऑडिट
  • उपयोग में आसानी

पहले पूछें कि आप किस चीज़ को, और किससे, बचा रहे हैं।

सामान्य व्यक्तिगत संचार में प्रमुख जोखिम खाता चोरी, असुरक्षित नेटवर्क, खोया उपकरण या अत्यधिक डेटा संग्रह हो सकते हैं।

अधिक जोखिम वाले संचार में आपको सत्यापित पहचानें, गायब होने वाले संदेशों की नीतियाँ, अतिरिक्त सुरक्षा वाले उपकरण, सख्त परिचालन प्रक्रियाएँ और स्वतंत्र सुरक्षा समीक्षा भी चाहिए हो सकती है।

जिस अंतिम उपकरण की सुरक्षा भंग हो चुकी हो, उसे एन्क्रिप्शन ठीक नहीं कर सकता, न ही वह विश्वसनीय प्राप्तकर्ता को संदेश साझा करने से रोक सकता है।

गोपनीयता सही अपेक्षाओं से शुरू होती है

भरोसेमंद मैसेंजर उपयोगकर्ताओं से यह मानने को नहीं कहता कि हर जोखिम गायब हो गया है।

वह समझाता है:

  • क्या सुरक्षित है
  • किन उपकरणों के पास कुंजियाँ हैं
  • सर्वर क्या संसाधित करता है
  • कौन-सा मेटाडेटा बचता है
  • पुनर्प्राप्ति कैसे काम करती है
  • E2EE कहाँ शुरू और खत्म होता है
  • कौन-से सुरक्षा उपाय अभी लागू नहीं हुए

यह स्पष्टता उपयोगकर्ताओं को जानकारी के आधार पर निर्णय लेने देती है।

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

अगले कदम के रूप में हानिरहित परीक्षण करें: एक संपर्क सत्यापित करें, नमूना अटैचमेंट भेजें, जुड़े उपकरण देखें, बैकअप का दायरा जाँचें और पुष्टि करें कि दोनों प्रतिभागी सेटिंग भरोसेमंद ढंग से इस्तेमाल कर सकते हैं। जिस गोपनीय सामग्री की रक्षा करना चाहते हैं, उसी से परीक्षण न करें।

अक्सर पूछे जाने वाले सवाल

संदेश ऐप सुरक्षित किससे बनता है?

सुरक्षित संदेश ऐप संरक्षित नेटवर्क संचार, मज़बूत प्रमाणीकरण, सावधान पहुँच नियंत्रण, सुरक्षित कुंजी प्रबंधन, ज़िम्मेदार डेटा व्यवहार और स्पष्ट रूप से दस्तावेज़ित गोपनीयता सीमाएँ जोड़ता है। निजी संदेश सामग्री के लिए एंड-टू-एंड एन्क्रिप्शन महत्वपूर्ण अतिरिक्त परत देता है।

क्या एन्क्रिप्टेड संदेश ऐप अपने-आप निजी होता है?

नहीं। ऐप संदेश सामग्री एन्क्रिप्ट करते हुए भी खाते की जानकारी, समय-मुहरें, सदस्यता, रसीदें, उपकरण जानकारी या अन्य मेटाडेटा संसाधित कर सकता है। गोपनीयता एन्क्रिप्शन और सेवा की व्यापक डेटा प्रक्रियाओं, दोनों पर निर्भर है।

क्या एंड-टू-एंड एन्क्रिप्शन छिपाता है कि मैं किसे संदेश भेजता हूँ?

ज़रूरी नहीं। E2EE मुख्य रूप से समर्थित संदेश सामग्री की रक्षा करता है। बातचीत पहुँचाने और सिंक करने के लिए सेवा को फिर भी भेजने वाले, पाने वाले, सदस्यता, समय और रूटिंग की जानकारी चाहिए हो सकती है।

क्या संदेश प्रदाता E2EE संदेश बहाल कर सकता है?

यह कुंजी और बैकअप डिज़ाइन पर निर्भर करता है। प्रदाता एन्क्रिप्टेड संदेश इतिहास रख सकता है, लेकिन उसे खोलने वाली निजी कुंजी उसके पास न हो। पुनर्प्राप्ति प्रणाली कुंजी तभी बहाल कर सकती है जब उपयोगकर्ता अलग गुप्त पुनर्प्राप्ति जानकारी दे।

क्या ब्राउज़र-आधारित सुरक्षित संदेश सेवा सुरक्षित है?

ब्राउज़र मज़बूत क्लाइंट-पक्षीय क्रिप्टोग्राफ़ी कर सकता है, लेकिन सुरक्षा फिर भी ऐप के कार्यान्वयन, ब्राउज़र की अखंडता, उपकरण सुरक्षा, कुंजी भंडारण, सर्वर से ऐप कोड की डिलीवरी और उपयोगकर्ता के एक्सटेंशन व ऑपरेटिंग सिस्टम पर निर्भर करती है।

क्या समूह चैट हमेशा एंड-टू-एंड एन्क्रिप्टेड होती हैं?

नहीं। कुछ सेवाएँ समूहों के लिए E2EE देती हैं, जबकि अन्य केवल सीधी बातचीत पर लागू करती हैं। सटीक सीमा के लिए प्रदाता के दस्तावेज़ देखें।

यदि मेरी एन्क्रिप्शन कुंजी बदल जाए तो क्या होता है?

कुंजी बदलाव नया उपकरण, दोबारा इंस्टॉल करना, कुंजी रीसेट या पुनर्प्राप्ति प्रक्रिया का परिणाम हो सकता है। सुरक्षित मैसेंजर को बदलाव दिखाना और संपर्कों को नया फ़िंगरप्रिंट सत्यापित करने देना चाहिए।

क्या अत्यधिक संवेदनशील संचार के लिए E2EE पर्याप्त है?

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

Livara Chat खोलें
CONTINUE THE THREADPrivate messaging ↗
YOU’VE REACHED THE ENDBack to the reading room ↗