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