IPsec पूर्व-साझा कुंजी: आपके द्वारा टाइप की गई स्ट्रिंग के पीछे की बाइट्स

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

गेटवे स्ट्रिंग के साथ क्या करता है

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

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

अतिरिक्त बाइट्स कहां से आते हैं

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

ग्लिफ़ नहीं बल्कि बाइट्स दिखाने वाले उपकरण से तुलना करें। printf '%s' "$PSK" | xxd | tail -2 मान का अंत हेक्स में छापता है, जहां एक भटका हुआ 0a या 20 स्पष्ट दिखता है। इसे दोनों सिरों पर करें और दोनों डंप की साथ-साथ तुलना करें। इसे उत्पन्न परीक्षण सामग्री पर करें, किसी उत्पादन गुप्त मान पर नहीं जिसे फिर शेल इतिहास में छोड़ दें।

एन्कोडेड होना एन्क्रिप्टेड होना नहीं है

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

Apple का IPSec शब्दकोश प्रकार के महत्व का उपयोगी उदाहरण है: यह SharedSecret को L2TP और Cisco IPsec पेलोड में साझा गुप्त प्रमाणीकरण विधि के लिए डेटा के रूप में दर्ज करता है। यह किसी विशिष्ट पेलोड में एक विशिष्ट गुण है, कोई सामान्य टेक्स्ट फ़ील्ड नहीं जिसे आप किसी दूसरे प्रोटोकॉल के लिए दोबारा उपयोग कर सकें जो संयोग से गुप्त मान मांगता हो।

दावा की गई सीमा एक संयोजन की होती है

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

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

ताकत नहीं, प्रस्तुति ठीक करें

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

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