आधी EAP पद्धत: VPN कोणता पासवर्ड हॅश वापरू शकते
VPN गुप्तता तपासते, वेब हॅश नाही. पद्धत वाचा, आणि मग तेच पासवर्ड चालू राहतील असे वचन देण्यापूर्वी साठ्यात काय आहे ते तपासा.
अनेक संघांकडे चालणारे वेब लॉगिन असते आणि त्याच तक्त्यातील प्रत्येक पासवर्ड नाकारणारे VPN असते. वेब अनुप्रयोग स्वतः गणलेल्या हॅशची तुलना करतो, तर बोगदा ग्राहकाला अशा पद्धतीने गुप्ततेची मालकी सिद्ध करायला सांगतो की सर्व्हरला ती तपासता आली पाहिजे. साठवलेल्या सामग्रीवर या वेगवेगळ्या अपेक्षा आहेत. या दोन्हींमधील फरकातच अशा प्रकल्पांपैकी बहुतेक अडकतात.
आधी पद्धत, मग स्कीमा
कोणतीही स्कीमा पाहण्यापूर्वी निवडलेली पद्धत कोणता पुरावा मागते ते लिहा. आव्हान-प्रतिसाद पद्धतीला अशी सामग्री लागते जिच्यातून सर्व्हर अपेक्षित प्रतिसाद मोजू शकेल, म्हणजे प्रत्यक्षात पासवर्ड किंवा सुसंगत व्युत्पन्न स्वरूप. संरक्षित बोगद्यात पासवर्ड घेऊन जाणाऱ्या पद्धतीला पडताळणीकर्त्याकडे पासवर्डच लागतो. ग्राहक संरचनेसाठी नाही, तर पडताळणीकर्त्याच्या अपेक्षेसाठी पद्धतीची कागदपत्रे वाचा, कारण ग्राहकाच्या अपेक्षा सहसा सोपा भाग असतो.
आधुनिक वेब फ्रेमवर्कने तयार केलेला मिठाचा हॅश यापैकी काहीही देत नाही. तो एक विशिष्ट तुलना तपासतो आणि ज्या गुप्ततेतून आला त्यात परत करता येत नाही.
आव्हान-प्रतिसाद मिठाचा हॅश वापरू शकत नाही
MSCHAPv2 ही आव्हान-प्रतिसाद देवाणघेवाण आहे, त्यामुळे सर्व्हरला पासवर्ड कधीच मिळत नाही आणि तो साठवलेल्या शब्दमालेशी तुलना करू शकत नाही. त्याला आधीच असलेल्या सामग्रीतून अपेक्षित प्रतिसाद काढावा लागतो, आणि म्हणूनच सुसंगत साठवलेली स्वरूपे इतकी अरुंद आहेत. प्रत्येक वापरकर्त्यासाठी मिठासह असलेले bcrypt किंवा Argon2 मूल्य अशा प्रकारे एकमार्गी आहे की ते देवाणघेवाण पूर्णपणे वगळते. खालील तक्ता पद्धतीच्या नावापासून नाही, साठवण्याच्या स्वरूपापासून सुरू होतो, कारण उत्तर साठवण्याचे स्वरूप ठरवते.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
SQL प्लगइनची कागदपत्रे strongSwan साठी संरचना आणि ओळखपत्रांसाठी स्वतःची स्कीमा परिभाषित करतात, आणि प्रकल्प ते प्लगइन अजूनही प्रायोगिक म्हणून चिन्हांकित करतो. त्यात काहीही अनुप्रयोगाच्या वापरकर्ता तक्त्याशी जुळवून घेत नाही किंवा कोणत्या हॅशिंग योजनेने साठवलेले मूल्य तयार केले याचा अंदाज लावत नाही. त्यामुळे वास्तववादी पर्याय म्हणजे गेटवे वापरू शकेल अशा साठ्यात स्थलांतर, किंवा देवाणघेवाण करू शकेल अशी विद्यमान साठ्यासमोरील प्रमाणीकरण सेवा. बाकी सर्व आत लपलेल्या गृहीतकासह जोडणी आहे.
RADIUS काम हलवते, अपेक्षा नाही
EAP RADIUS सर्व्हरकडे सोपवल्याने पडताळणी कुठे होते ते बदलते आणि सहसा लेखापरीक्षणाचा माग सुधारतो. ते एकमार्गी हॅशमधून पासवर्ड परत मिळवत नाही, त्यामुळे प्रमाणीकरण सेवेला ती ज्या पद्धतीचा शेवट करते त्याच्याशी सुसंगत सामग्री अजूनही लागते. संघांना हे RADIUS मार्ग बांधल्यानंतर आणि दुसऱ्या टोकाला तीच भिंत भेटल्यावर कळते.
जिथे RADIUS सर्व्हर सुसंगत ओळखपत्र असलेली निर्देशिका वाचू शकतो तिथे रचना चालते आणि VPN गेटवे सोपा राहतो. जिथे तो वाचू शकत नाही तिथे प्रामाणिक उत्तर दुसरी जोडणी नाही, नोंदणीतील बदल आहे. पुरवठा आणि रद्दीकरण हे ओळख ज्याच्याकडे आहे त्याचे असते, त्यामुळे समर्थित समक्रमण प्रक्रियेशिवाय नकल केलेला तक्ता एकच साइन-इन नाही, तर ओळखपत्रांचा दुसरा जीवनचक्र आहे. कोणी फक्त एकाच ठिकाणी पासवर्ड रीसेट केल्यावर तो पहिल्यांदा तफावत दाखवतो, आणि दोन्ही प्रणालींमध्ये असलेले खाते प्रत्येकात वेगळे वागू लागेपर्यंत ती तफावत शांत राहते.
निर्देशिका वाचणाऱ्या खात्याला त्या वाचनापुरते मर्यादित ठेवा आणि गेटवे स्वतःच्या संरचनेसाठी वापरत असलेल्या खात्यापासून वेगळे ठेवा. सामायिक प्रशासकीय खाते केवळ-वाचन रचनेचे खूप मोठ्या परिणाम-त्रिज्येत रूपांतर करते.
खाते कुठे असावे
सामग्रीचा प्रश्न सुटल्यावर दोन रचना उरतात. गेटवे स्वतःच पुरता वाचतो असे छोटे ओळखपत्र साठवण ते ठेवू शकते, किंवा कॉर्पोरेट निर्देशिकेसमोर उभी असलेली प्रमाणीकरण सेवा ते सोपवू शकते.
पहिली विचार करायला सोपी आणि वापरकर्त्यासाठी वाईट आहे, कारण त्याच्याकडे सांभाळायला दुसरा पासवर्ड राहतो. दुसरी एक ओळख राखते आणि आता कोणी जोडण्यापूर्वी सुरू असावी लागणाऱ्या सेवेवर अवलंबून राहते. दोन्हीपैकी कोणतेही चुकीचे नाही, पण निवड गेटवे संरचनेच्या शेजारी नोंदवावी, अन्यथा पुढील अभियंता दुसरी निवडली गेली असे गृहीत धरेल. तुम्ही काहीही निवडा, खालील दोन आदेश तेच आहेत जे बदलण्यापूर्वी सध्याची स्थिती दाखवतात.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsखाते प्रमाणीकरण अधिकृतताही ठरवत नाही. गट सदस्यत्व, उपकरणाची स्थिती आणि नेटवर्क परवानगी यांना वापरकर्त्याने आवश्यक ओळख सिद्ध केल्यानंतरही स्पष्ट मॅपिंग लागते. पूर्णपणे प्रमाणित होऊन काहीही अधिकृत न करणारे कनेक्शन धोरणाचा परिणाम आहे, पद्धतीतील दोष नाही.