एन्क्रिप्ट करने का तरीका

आम तौर पर, एन्क्रिप्ट (सुरक्षित) करने का तरीका सुरक्षा से जुड़ा विषय होता है. हालांकि, निजता के लिए भी यह बेहद ज़रूरी है. एन्क्रिप्शन का लक्ष्य अन्य लोगों को एन्क्रिप्ट की गई जानकारी को पढ़ने से रोकना है... लेकिन आपकी जानकारी को अन्य लोगों से पढ़ने से रोकना, उसे निजी रखने का एक तरीका है. उपयोगकर्ता के पास अक्सर इसकी सीमा होती है कि वह खुद यह काम कितनी बार कर सकता है. हालांकि, जिस सेवा का इस्तेमाल किया जा रहा है उसे उपलब्ध कराने वाली कंपनी के तौर पर आपकी मदद से, उपयोगकर्ता के डेटा को एन्क्रिप्ट (सुरक्षित) करने से, उसके डेटा को सुरक्षित रखने में मदद मिलती है.

उपयोगकर्ता की निजता की सुरक्षा के लिए, एन्क्रिप्ट (सुरक्षित) करने के तीन तरीके हैं: एक जगह से दूसरी जगह भेजने के दौरान एन्क्रिप्ट (सुरक्षित) करने का तरीका, ऐक्टिव रहने के दौरान एन्क्रिप्शन, और एंड-टू-एंड एन्क्रिप्शन (E2EE):

• ट्रांसफ़र के दौरान एन्क्रिप्ट (सुरक्षित) करने का तरीका, उपयोगकर्ता और आपकी साइट के बीच डेटा एन्क्रिप्ट (सुरक्षित) करके रखता है. इसका मतलब है, एचटीटीपीएस. आपने शायद अपनी साइटों के लिए एचटीटीपीएस पहले ही सेट अप कर लिया हो, लेकिन क्या आपको यकीन है कि आपकी साइटों पर ट्रांसफ़र का पूरा डेटा एन्क्रिप्ट (सुरक्षित) किया गया है? रीडायरेक्ट और एचएसटीएस, इन कामों के लिए होते हैं. इनके बारे में नीचे बताया गया है और ये आपके एचटीटीपीएस सेटअप का हिस्सा होने चाहिए.
• इनऐक्टिव रहने के दौरान, एन्क्रिप्ट (सुरक्षित) करने की सुविधा आपके सर्वर पर सेव किए गए डेटा को एन्क्रिप्ट (सुरक्षित) करने का तरीका है. यह डेटा के गलत इस्तेमाल से बचाव करता है और यह आपके डेटा की सुरक्षा का एक अहम हिस्सा है.
• पूरी तरह सुरक्षित (E2EE) डेटा को आपके सर्वर तक पहुंचने से पहले ही क्लाइंट पर एन्क्रिप्ट (सुरक्षित) किया जाता है. ऐसा करने से, उपयोगकर्ता के डेटा को आपसे भी सुरक्षित रखा जाता है. उपयोगकर्ताओं का डेटा सेव किया जा सकता है, लेकिन पढ़ा नहीं जा सकता. इसे लागू करना मुश्किल है और यह सभी तरह के ऐप्लिकेशन के लिए सही नहीं है. हालांकि, यह उपयोगकर्ता की निजता बनाए रखने में बहुत मदद करता है, क्योंकि इनके डेटा को कोई नहीं देख सकता.

एचटीटीपीएस

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

अपनी वेबसाइट को एचटीटीपीएस पर दिखाने के लिए, आपको एसएसएल सर्टिफ़िकेट की ज़रूरत होगी. इन्हें Let's Encrypt की मदद से मुफ़्त में बनाया जा सकता है या अगर इनका इस्तेमाल किया जा रहा है, तो ये अक्सर आपकी होस्टिंग सेवा की मदद से उपलब्ध कराई जा सकती हैं. किसी ऐसी तीसरे पक्ष की सेवा का भी इस्तेमाल किया जा सकता है जो आपकी वेब सेवा को "प्रॉक्सी" कर सकती है और एचटीटीपीएस के साथ-साथ कैश मेमोरी और सीडीएन सेवाएं दे सकती है. ऐसी सेवाओं के कई उदाहरण हैं, जैसे कि Cloudflare और फ़ास्टली. ये सेवाएं आपके मौजूदा इन्फ़्रास्ट्रक्चर पर निर्भर करती हैं. इनमें से किस तरह की सेवाओं का इस्तेमाल किया जाना चाहिए. पहले, एचटीटीपीएस को लागू करना बोझ या महंगा हो सकता था. इसलिए, इसका इस्तेमाल सिर्फ़ पेमेंट वाले पेजों या खास तौर पर सुरक्षित ऑरिजिन पर किया जाता था. हालांकि, मुफ़्त में उपलब्ध सर्टिफ़िकेट, स्टैंडर्ड में सुधार , और ब्राउज़र के बड़े प्रसार ने वे सभी समस्याएं हटा दी हैं.

ऐसा करें

• सभी चीज़ों के लिए (जो भी तरीका चुनें) अपने सर्वर पर एचटीटीपीएस चालू करें.
• अपने सर्वर के सामने प्रॉक्सी का इस्तेमाल करें, जैसे कि Cloudflare (httpsiseasy.com/ इस प्रोसेस के बारे में बताता है).
• Let's Encrypt आपको अपना 'Let's Encrypt एसएसएल सर्टिफ़िकेट बनाने की प्रोसेस के बारे में बताएगी.
• अगर आपको अपना सर्टिफ़िकेट बनाना है और अपना सर्टिफ़िकेट बनाना है, तो सीधे खोलने के लिए इसका इस्तेमाल करें. साथ ही, इस पर अपनी पसंद के सर्टिफ़िकेट अथॉरिटी (सीए) से हस्ताक्षर कराएं. (एचटीटीपीएस चालू करें, इस बारे में ज़्यादा जानकारी देता है).

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

सर्टिफ़िकेट जनरेट करने और सीए से उन पर हस्ताक्षर कराने का मतलब है कि एसएसएल प्रोसेस का इस्तेमाल किया जाता था. हालांकि, अगर सेवा देने वाली कंपनी साथ देती है या आपके सर्वर की टीम इसके लिए तकनीकी रूप से अच्छी है और यह मुफ़्त है, तो 'Let's Encrypt का इस्तेमाल करना आसान है. अगर आप किसी चीज़ का इस्तेमाल क्लाउड होस्टिंग के मुकाबले बेहतर लेवल पर कर रहे हैं, तो सेवा देने वाली कंपनी एसएसएल को सेवा के तौर पर उपलब्ध कराती है. इसलिए, इसकी जांच करना सही रहेगा.

क्यों शुरू करें?

सुरक्षा आपकी निजता की कहानी का एक हिस्सा है: आपको यह दिखा पाना चाहिए कि किसी रुकावट से बचने के लिए, आपका डेटा सुरक्षित रखा जाता है. इससे लोगों का भरोसा जीतने में मदद मिलती है. अगर एचटीटीपीएस का इस्तेमाल नहीं किया जाता है, तो ब्राउज़र आपकी साइटों को "सुरक्षित नहीं है" के तौर पर भी फ़्लैग कर रहे हैं (और कुछ समय से हैं). मौजूदा JavaScript एपीआई अक्सर सिर्फ़ एचटीटीपीएस पेजों ("सुरक्षित ऑरिजिन") के लिए उपलब्ध होते हैं. यह आपके उपयोगकर्ताओं को, आईएसपी के वेब इस्तेमाल को न देखे जाने से भी सुरक्षित रखता है. यह सबसे सही तरीका है. फ़िलहाल, वेबसाइटों के लिए एचटीटीपीएस का इस्तेमाल न करने की कोई वजह नहीं है.

ब्राउज़र किसी एचटीटीपी (सुरक्षित नहीं) पेज को कैसे प्रज़ेंट करते हैं

एचटीटीपीएस पर रीडायरेक्ट करें

अगर आपकी साइट http: और https: दोनों यूआरएल पर उपलब्ध है, तो आपको एचटीटीपी यूआरएल के सभी ऐक्सेस को https पर रीडायरेक्ट करना चाहिए. ऐसा ऊपर बताई गई वजहों से है. इससे यह भी पक्का होता है कि अगर आपकी साइट लोकप्रिय हो जाती है, तो वह whynohttps.com पर न दिखे. इसे कैसे किया जा सकता है, यह आपके इन्फ़्रास्ट्रक्चर पर निर्भर करता है. अगर आपको AWS पर होस्ट किया गया है, तो क्लासिक या ऐप्लिकेशन लोड बैलेंसर का इस्तेमाल किया जा सकता है. Google Cloud भी ऐसा ही है. Azure में, Front Door बनाया जा सकता है; Node with Express में request.secure की जांच करें; Ngnx में सभी पोर्ट 80 को पकड़ें और 301 को रिटर्न करें; और Apache में, RewriteRule का इस्तेमाल करें. अगर आपने किसी होस्टिंग सेवा का इस्तेमाल किया है, तो इस बात की काफ़ी संभावना है कि वे आपके लिए एचटीटीपीएस यूआरएल पर रीडायरेक्ट अपने-आप मैनेज कर लें. इनमें से कई, Netlify, Firebase, और GitHub पेज भी शामिल हैं.

HSTS

एचएसटीएस का छोटा रूप "एचटीटीपी स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी" होता है. इसकी मदद से, ब्राउज़र को लॉक करके, अपनी सेवा के लिए एचटीटीपीएस का इस्तेमाल किया जा सकता है. अगर आप एचटीटीपीएस पर माइग्रेट करने के बाद संतुष्ट हैं या आपने पहले ही ऐसा कर लिया है, तो अपने आउटगोइंग रिस्पॉन्स में स्ट्रिक्ट-ट्रांसपोर्ट-सिक्योरिटी एचटीटीपी रिस्पॉन्स हेडर जोड़ें. जिस ब्राउज़र ने आपकी साइट को पहले ऐक्सेस किया है उसने इस हेडर को देखा होगा. इसके बाद, अगर आपने एचटीटीपी का अनुरोध किया है, तो भी वह ब्राउज़र इस साइट को अपने-आप एचटीटीपीएस के तौर पर ऐक्सेस करेगा. इससे, रीडायरेक्ट करने से बचा जा सकता है, जैसे कि ऊपर बताया गया है: ऐसा लगता है कि ब्राउज़र एचटीटीपीएस इस्तेमाल करने के लिए, आपकी सेवा के सभी अनुरोधों को चुपचाप "अपग्रेड" करता है.

इसी तरह, अपने पेजों के साथ अपग्रेड-असुरक्षित-अनुरोध हेडर दिखाया जा सकता है. यह Strict-Transport-Security से अलग है, लेकिन यह उससे जुड़ा है. अगर Upgrade-Insecure-Requests: 1 को जोड़ा जाता है, तो इस पेज से दूसरे रिसॉर्स (इमेज, स्क्रिप्ट) पर किए गए अनुरोध, एचटीटीपीएस के तौर पर किए जाएंगे. भले ही, लिंक एचटीटीपी हो. हालांकि, ब्राउज़र, पेज को एचटीटीपीएस के तौर पर दिखाने के लिए दोबारा अनुरोध नहीं करेगा और न ही ब्राउज़र अगली बार उसे याद रखेगा. व्यावहारिक तौर पर, अगर आपकी किसी मौजूदा साइट को एचटीटीपीएस के बहुत सारे लिंक वाली साइट में बदला जा रहा है और कॉन्टेंट में लिंक यूआरएल को बदलना मुश्किल है, तो अपग्रेड-असुरक्षित-अनुरोध करना फ़ायदेमंद होता है, लेकिन जहां तक हो सके कॉन्टेंट में बदलाव करना बेहतर है.

एचएसटीएस मुख्य रूप से सुरक्षा से जुड़ी सुविधा है: यह आपकी साइट को एचटीटीपीएस पर "लॉक" करता है. ऐसा उन लोगों के लिए किया जाता है जो साइट पर पहले भी आ चुके हैं. हालांकि, जैसा कि ऊपर बताया गया है, निजता के लिए एचटीटीपीएस और एचटीटीपीएस के लिए एचएसटीएस अच्छा है. इसी तरह, अगर आप अपना पूरा कॉन्टेंट अपडेट कर रहे हैं, तो अपग्रेड-असुरक्षित-अनुरोधों की वाकई ज़रूरत नहीं है, लेकिन यह "बेल्ट और ब्रेसेस" का एक उपयोगी तरीका है, जिससे यह पक्का किया जा सकता है कि आपकी साइट हमेशा एचटीटीपीएस बनी रहे.

ऐसा करें

आउटगोइंग जवाबों में एचएसटीएस हेडर जोड़ें:

Strict-Transport-Security: max-age=300; includeSubDomains

max-age पैरामीटर से यह तय होता है कि ब्राउज़र को कितने सेकंड के लिए, एचटीटीपीएस अपग्रेड को याद रखना चाहिए और उसे लागू करना चाहिए. (यहां हमने इसे 300 सेकंड, यानी पांच मिनट पर सेट किया है.) आपको इसे 63,072,000 पर सेट करना होगा, जो कि दो साल के बराबर है. यह hstspreload.org का सुझाव है. हालांकि, कोई समस्या होने पर इसे ठीक करना काफ़ी मुश्किल होता है. इसलिए, हमारा सुझाव है कि आप शुरुआत में, किसी संख्या को कम (300) पर सेट करें. इससे यह पता चल जाएगा कि किसी चीज़ में गड़बड़ी नहीं हुई है. इसके बाद, इस संख्या को अलग-अलग चरणों में बढ़ाएं.

अपने आउटगोइंग जवाबों में Upgrade-Insecure-Requests हेडर जोड़ें:

Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests

पूरी तरह सुरक्षित (E2EE)

उपयोगकर्ता के डेटा को निजी बनाए रखने का एक अच्छा तरीका यह है कि उसे उपयोगकर्ता के अलावा, आपके साथ-साथ किसी और को न दिखाया जाए. इससे आपको उपयोगकर्ताओं का भरोसा रखने में मदद मिलती है: अगर आपके पास अपने उपयोगकर्ता का डेटा नहीं है, तो यह साफ़ तौर पर पता चलता है कि इस डेटा का इस्तेमाल कुछ भी नहीं किया जा सकता, जो वह नहीं करना चाहेगा. ऐसा करने का एक तरीका यह है कि उपयोगकर्ता के डेटा को उनके डिवाइस में ही न छोड़ा जाए, ताकि हर चीज़ को क्लाइंट-साइड पर सेव किया जा सके. यह तरीका काम करता है, लेकिन पूरी तरह से क्लाइंट-साइड ऐप्लिकेशन की कुछ सीमाएं होती हैं: ब्राउज़र का डेटा स्टोरेज सीमित किया जा सकता है. साथ ही, कुछ ब्राउज़र में, हो सकता है कि उन्हें थोड़ी-बहुत या बिना किसी चेतावनी के मिटा दिया जाए. लैपटॉप और मोबाइल फ़ोन जैसे दो डिवाइस में अपना डेटा ऐक्सेस कर पाना भी मुश्किल या नामुमकिन है. इस वजह से, सर्वर पर सामान्य रूप से डेटा भेजना फ़ायदेमंद हो सकता है. हालांकि, इसे एक ऐसी कुंजी से एन्क्रिप्ट (सुरक्षित) करना चाहिए जो उपयोगकर्ता के पास ही हो, ताकि सर्वर इसे ऐक्सेस न कर सके (क्योंकि यह इसे डिक्रिप्ट नहीं कर सकता) लेकिन इसे स्टोर कर सके.

यह कैसे काम करती है?

इस तरीके का इस्तेमाल, अक्सर मैसेजिंग ऐप्लिकेशन में किया जाता है. इसे "एंड-टू-एंड एन्क्रिप्शन (E2EE)" या "e2e" कहा जाता है. इस तरह, जिन लोगों को एक-दूसरे की कुंजियों का पता होता है वे अपने मैसेज को आगे-पीछे करके, मैसेज को एन्क्रिप्ट और डिक्रिप्ट कर सकते हैं. साथ ही, मैसेज सेवा देने वाली कंपनी के ज़रिए उन्हें भेज सकते हैं. हालांकि, मैसेज सेवा देने वाली कंपनी (जिसके पास वे कुंजियां नहीं होती) मैसेज नहीं पढ़ सकता. ज़्यादातर ऐप्लिकेशन, मैसेजिंग ऐप्लिकेशन नहीं होते हैं, लेकिन डेटा को स्थानीय तौर पर सेव करने के साथ-साथ एन्क्रिप्ट (सुरक्षित) करके, सर्वर पर भेजने के लिए भी दो तरीकों को जोड़ा जा सकता है. जैसे, सिर्फ़ क्लाइंट-साइड डेटा स्टोर और डेटा को एन्क्रिप्ट (सुरक्षित) करने की एक कुंजी. यह समझना ज़रूरी है कि इस तरीके की सीमाएं हैं: ऐसा सभी सेवाओं के लिए मुमकिन नहीं है. खास तौर पर तब इसका इस्तेमाल नहीं किया जा सकता, जब सेवा देने वाले के तौर पर आपको उपयोगकर्ता के सेव किए जा रहे कॉन्टेंट के ऐक्सेस की ज़रूरत हो. जैसा कि इस सीरीज़ के भाग 2 में बताया गया है, डेटा कम करने के नियम का पालन करना सबसे अच्छा है. अगर हो सके, तो डेटा इकट्ठा करने से बचें. अगर उपयोगकर्ता को डेटा स्टोरेज की ज़रूरत हो, लेकिन आपको सेवा देने के लिए उस डेटा के ऐक्सेस की ज़रूरत न हो, तो डेटा को पूरी तरह सुरक्षित करने की सुविधा (E2EE) इसका अच्छा विकल्प है. अगर ऐसी सेवाएं दी जाती हैं जिनके लिए यह पता होना ज़रूरी है कि उपयोगकर्ता सेवा देने के लिए क्या स्टोर करता है, तो पूरी तरह सुरक्षित (E2EE) करना सही नहीं है. अगर आप ऐसा नहीं करते हैं, तो अपनी वेब सेवा के क्लाइंट-साइड JavaScript से सर्वर को भेजे जाने वाले किसी भी डेटा को एन्क्रिप्ट (सुरक्षित) किया जा सकता है. साथ ही, उस डेटा को डिक्रिप्ट भी किया जा सकता है जो सर्वर को भेजा जाता है.

उदाहरण: Excalidraw

Excalidraw, ब्लॉग पोस्ट में ऐसा ही करता है और उसके बारे में बताता है. यह वेक्टर ड्रॉ करने वाला एक ऐप्लिकेशन है, जो ड्रॉइंग को सर्वर पर सेव करता है. इन ड्रॉइंग को किसी भी क्रम में चुनी गई कुंजी से एन्क्रिप्ट (सुरक्षित) किया जाता है. Excalidraw, काफ़ी कम कोड के साथ इस एंड-टू-एंड एन्क्रिप्शन (E2EE) को लागू कर सकता है. इसकी एक वजह यह है कि अब क्रिप्टोग्राफ़िक लाइब्रेरी, window.crypto वाले ब्राउज़र में पहले से मौजूद हैं. यह JavaScript एपीआई का सेट है, जो सभी आधुनिक ब्राउज़र में काम करता है. क्रिप्टोग्राफ़ी बहुत मुश्किल है और एल्गोरिदम को लागू करने के कई चरण होते हैं. ब्राउज़र का काम आसानी से करने पर, वेब डेवलपर के लिए एन्क्रिप्शन को ज़्यादा आसानी से ऐक्सेस किया जा सकता है. साथ ही, इससे एन्क्रिप्ट (सुरक्षित) किए गए डेटा की मदद से निजता लागू करना आसान हो जाता है. जैसा कि Excalidraw ने अपने राइटअप में बताया है, एन्क्रिप्शन की क्लाइंट-साइड पर बनी रहती है, क्योंकि यह यूआरएल फ़्रैगमेंट का हिस्सा होती है: जब कोई ब्राउज़र किसी यूआरएल पर जाता है https://example.com/path?param=1#fraghere, यूआरएल का पाथ (/path) और पैरामीटर (param=1) सर्वर (example.com) को पास किए जाते हैं, लेकिन फ़्रैगमेंट (fraghere) मौजूद नहीं होता है और इसलिए सर्वर को यह कभी नहीं दिखता. इसका मतलब यह है कि भले ही एन्क्रिप्ट (सुरक्षित) किया गया डेटा, सर्वर से होकर भी जाता है, लेकिन एन्क्रिप्ट (सुरक्षित) करने वाली कुंजी, डेटा को सुरक्षित रखती है. इस वजह से, डेटा पूरी तरह सुरक्षित (E2EE) होता है.

सीमाएं

उपयोगकर्ता के डेटा को एन्क्रिप्ट करने का यह तरीका पूरी तरह सुरक्षित नहीं है. इससे आपके उपयोगकर्ताओं पर भरोसा बढ़ता है, लेकिन यह इसे पूरी तरह से नहीं बदल सकता. आपके उपयोगकर्ताओं को अब भी आपकी सेवा पर भरोसा करना होगा, क्योंकि सेवा देने वाली कंपनी किसी भी समय, कुछ मिलते-जुलते JavaScript से क्लाइंट-साइड JavaScript की जगह ले सकती है, जो डेटा को बिना रुकावट के एन्क्रिप्ट (सुरक्षित) नहीं करती है. हालांकि, उपयोगकर्ता के तौर पर यह पता लगाना बहुत मुश्किल है कि आपकी वेबसाइट ने ऐसा किया है या नहीं. हालांकि, आपके उपयोगकर्ताओं को अब भी इस बात पर भरोसा करना होगा कि वे पूरी तरह से एन्क्रिप्ट (सुरक्षित) नहीं हैं.

यह ध्यान रखना भी ज़रूरी है कि डेटा को पूरी तरह सुरक्षित (E2EE) करने का एक मकसद, आपको यानी साइट के मालिक को डेटा देखने से रोकना है. यह निजता के लिए अच्छा है, लेकिन इसका मतलब यह भी है कि अगर समस्याएं होती हैं, तो आप मदद नहीं कर सकते. कम शब्दों में कहें, तो एंड-टू-एंड एन्क्रिप्शन (E2EE) का इस्तेमाल करने वाली सेवा, उपयोगकर्ता को एन्क्रिप्शन कुंजियों की ज़िम्मेदारी दे सकती है. (ऐसा हो सकता है कि यह साफ़ तौर पर पता न हो या साफ़ तौर पर न पता हो, लेकिन किसी के पास उसकी कुंजी होती है और अगर डेटा को आपसे निजी रखा जाता है, तो यह आप नहीं हैं.) अगर वे कुंजियां खो जाती हैं, तो आपको मदद के लिए कुछ नहीं करना पड़ेगा. साथ ही, हो सकता है कि उन कुंजियों से एन्क्रिप्ट (सुरक्षित) किया गया डेटा भी गायब हो जाए. निजता और उपयोगिता के बीच एक संतुलन बनाया जा सकता है: एन्क्रिप्शन का इस्तेमाल करके सभी लोगों के डेटा को निजी रखें. साथ ही, उपयोगकर्ताओं को क्रिप्टोलॉजी विशेषज्ञ बनने के लिए मजबूर न करें, जो सुरक्षित तरीके से अपनी कुंजियों को मैनेज करते हों.

एन्क्रिप्ट (सुरक्षित) करने की सुविधा इनऐक्टिव है

ट्रांज़िट में अपने उपयोगकर्ताओं के डेटा को एन्क्रिप्ट करने के साथ-साथ, आपके द्वारा सर्वर पर स्टोर किए गए डेटा को एन्क्रिप्ट करने पर भी विचार करना आवश्यक है. इससे डेटा के गलत इस्तेमाल से बचने में मदद मिलती है, क्योंकि आपके सेव किए गए डेटा को बिना अनुमति के ऐक्सेस करने वाले लोगों के पास एन्क्रिप्ट (सुरक्षित) किया गया डेटा होगा. उम्मीद है कि उनके पास इसे डिक्रिप्ट करने की कुंजियां नहीं होंगी. इनऐक्टिव डेटा को एन्क्रिप्ट (सुरक्षित) करने के दो अलग-अलग तरीके हैं. एन्क्रिप्ट (सुरक्षित) करने के दो तरीके हैं: पहला एन्क्रिप्ट (सुरक्षित) करने का तरीका और क्लाउड स्टोरेज की सेवा देने वाली कंपनी (अगर क्लाउड स्टोरेज की सेवा देने वाली कंपनी का इस्तेमाल किया जा रहा है) एन्क्रिप्ट (सुरक्षित) करने की सुविधा. स्टोरेज उपलब्ध कराने वाली कंपनी के एन्क्रिप्शन से आपके सॉफ़्टवेयर के ज़रिए डेटा के गलत इस्तेमाल से सुरक्षा नहीं मिलती (क्योंकि स्टोरेज उपलब्ध कराने वाली सेवा इस्तेमाल करने वाले के तौर पर उन्हें एन्क्रिप्ट (सुरक्षित) करना आम तौर पर पारदर्शी होता है. हालांकि, सेवा देने वाली कंपनी के इन्फ़्रास्ट्रक्चर में होने वाले उल्लंघन के मामलों में, एन्क्रिप्ट (सुरक्षित) करने की सुविधा कारगर साबित होती है. आम तौर पर, इसे चालू करना आसान होता है और इसलिए, इस पर विचार करना फ़ायदेमंद होता है. यह फ़ील्ड तेज़ी से बदलता रहता है और आपकी सुरक्षा टीम (या आपकी टीम के सुरक्षा की जानकारी रखने वाले इंजीनियर) इस बारे में सबसे सही सलाह देते हैं. हालांकि, क्लाउड स्टोरेज उपलब्ध कराने वाली सभी कंपनियां Amazon S3, डिफ़ॉल्ट रूप से Azure Storage, और Google Cloud Storage में डिफ़ॉल्ट रूप से ब्लॉक स्टोरेज, और डेटाबेस डेटा स्टोरेज के लिए एन्क्रिप्शन की सुविधा देती हैं AWS RDS, और Azure SQL.Google अगर आप क्लाउड स्टोरेज की सेवा देने वाली कंपनी का इस्तेमाल कर रहे हैं, तो इस बारे में ज़्यादा जानने के लिए. उपयोगकर्ता के डेटा को डेटा के गलत इस्तेमाल से बचाने के लिए, उसे खुद ही एन्क्रिप्ट (सुरक्षित) करना ज़्यादा मुश्किल है. ऐसा इसलिए है, क्योंकि एन्क्रिप्ट (सुरक्षित) करने वाली कुंजियों को सुरक्षित रूप से मैनेज करने और उन्हें हमलावरों के लिए उपलब्ध कराए बिना, कोड पर उपलब्ध कराने की प्रोसेस करना चुनौती भरा काम है. सुरक्षा से जुड़े मुद्दों पर सलाह देने के लिए यह सबसे सही जगह नहीं है. इसके बारे में, सुरक्षा के जानकार इंजीनियर या ऐसी टीम से बात करें जो सुरक्षा के लिए बनी हो.