एक एनकोडेड VPN सीक्रेट के लिए कोई ‘डिक्रिप्ट’ नहीं होता

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

मान को वेब डिकोडर और सार्वजनिक फ़ोरम पोस्ट दोनों से दूर रखें, क्योंकि एनकोडेड सीक्रेट भी सीक्रेट ही रहता है।

एनकोडिंग, एन्क्रिप्शन और वेरिफ़ायर तीन अलग चीज़ें हैं

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

किसी स्ट्रिंग को Base64 कहना यह साबित नहीं करता कि उसमें क्या है। यह कुंजी में, क्रमबद्ध संरचना में या यादृच्छिक पैडिंग में डिकोड हो सकती है, और पाठ का रूप इस बारे में कुछ नहीं कहता कि कौन-सा।

छूने से पहले फ़ील्ड पहचानें

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

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

वसूली एक अधिकृत प्रक्रिया है, डिकोडर नहीं

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

जब मालिक मान को वापस नहीं पा सकता या सुरक्षित रूप से दोबारा जारी नहीं कर सकता, तो उत्तर नया क्रेडेंशियल और अद्यतन पीयर कॉन्फ़िगरेशन है। यह कटओवर वाली परियोजना है, कोई आदेश नहीं।

साझा सीक्रेट बदलना एक समन्वित परिवर्तन है

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

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

दर्ज करें कि नया मान कहाँ रहता है और उसका मालिक कौन है। अगली घटना यही पूछेगी, डिकोडर नहीं।