IPsec पूर्व-साझा की: तुम्ही टाइप केलेल्या स्ट्रिंगमागील बाइट्स

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

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

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

त्यामुळे उपयुक्त प्रश्न कधीही «हे सारखे दिसतात का» नसून «प्रत्येक अंमलबजावणी कोणता नेमका बाइट क्रम हॅश करते» हा आहे।

अतिरिक्त बाइट्स कुठून येतात

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

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

एन्कोड केलेले म्हणजे एन्क्रिप्ट केलेले नाही

कॉन्फिगरेशन निर्यात बहुतेक वेळा गुप्त मूल्य आधार एन्कोडिंगमध्ये वाहते, कधी प्रत्येक साठ किंवा शहात्तर अक्षरांनी ओळ तुटते, कधी पॅडिंगसह। जर एका बाजूने डीकोड केलेल्या बाइट्सची अपेक्षा केली आणि तुम्ही एन्कोड केलेला मजकूर पेस्ट केला, तर तुम्ही वेगळा पासवर्ड पाठवला नाही, तुम्ही छापण्यायोग्य अक्षरांनी बनलेला खूप लांब पासवर्ड पाठवला आहे। Base64 कोणतीही गोपनीयता देत नाही, म्हणूनच एन्कोड केलेले गुप्त मूल्य दुसऱ्या मतासाठी कधीही फोरममध्ये पेस्ट करू नये।

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

दावा केलेली मर्यादा एका संयोजनाची असते

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

मर्यादा खरोखर लागू होत असल्यास, उत्तर तिला बसणारी समर्थित क्रेडेन्शियल रचना आहे, मजबूत गुप्त मूल्याची लहान आवृत्ती नाही। अंदाजित मर्यादा पूर्ण करण्यासाठी उत्पादन की कापली तर तिची ताकद कायमची कमी होते आणि अशी प्रणाली तयार होते जिची कागदपत्रे तिच्या सुरक्षेशी आता जुळत नाहीत।

ताकद नाही, सादरीकरण दुरुस्त करा

सादरीकरण निश्चित केल्यानंतर प्रमाणीकरण अयशस्वी झाल्यास, प्रमाणीकरण टप्प्यावरील प्रभावी धोरण वाचा: कोणती पद्धत वाटाघाटीत आहे, कोणती सहकारी ओळख अपेक्षित आहे, आणि गेटवे तुम्ही विचार करत असलेल्या कनेक्शनशी जुळतो का। क्रमाक्रमाने कमकुवत होणारे अंदाज निदान नाहीत, ते सहाय्य तिकीट जोडलेले संथ अवनती आहेत।

आवश्यक क्रेडेन्शियल संस्थेचे मानक पूर्ण करू शकत नसेल, तर रचना पूर्ण करू शकणाऱ्याकडे बदला। पुरेशा एन्ट्रॉपीसह साझा गुप्त मूल्य, एकदा तयार केलेले, व्यवस्थापित फील्डमध्ये साठवलेले आणि कधीही प्रकाशित न केलेले, पूर्णपणे चांगले उत्तर आहे; त्याची लहान आवृत्ती नाही।