पहले 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खाता प्रमाणीकरण प्राधिकरण भी तय नहीं करता। समूह सदस्यता, डिवाइस की स्थिति और नेटवर्क अनुमति को उपयोगकर्ता द्वारा आवश्यक पहचान सिद्ध करने के बाद भी स्पष्ट मैपिंग चाहिए। जो कनेक्शन पूरी तरह प्रमाणित होता है और कुछ भी प्राधिकृत नहीं करता, वह नीति का परिणाम है, विधि की खराबी नहीं।