कुनै पनि VPN लगइनका बारेमा चार प्रश्न विचार गर्नुहोस्: यात्राको क्रममा पासवर्डलाई केले जोगाउँछ, कुन घटकले त्यो प्राप्त गर्छ, त्यो घटकले त्यससँग के गर्छ, र पछि के भण्डारण गरिन्छ। हरेक उत्तर फरक नियन्त्रण हो, र एउटामा दिइएको बलियो उत्तरले अरूबारे केही भन्दैन। गल्ती भनेको टनेल इन्क्रिप्शनलाई चारैलाई समेट्छ जस्तो व्यवहार गर्नु हो। यसले पहिलोलाई मात्र समेट्छ।

सत्र इन्क्रिप्ट भयो कि भएन भनेर होइन, सत्र कसले अन्त्य गर्छ भनेर सोध्नुहोस्।

ठ्याक्कै कसका लागि इन्क्रिप्ट गरिएको?

TLS ले ग्राहक र जडान अन्त्य गर्नेबीचको पासवर्ड जोगाउँछ। यदि त्यो अन्तिम बिन्दु VPN गेटवे हो भने, गेटवेको प्रमाणीकरण कोडले खुला पाठमा पासवर्ड देख्छ, त्यसलाई मान्य गर्छ, र त्यसलाई वा त्यसबाट प्राप्त मान अगाडि पठाउँछ। यो अभिप्रेत डिजाइन हो, चुहावट होइन। बाटोमा रहेको सञ्जाल पर्यवेक्षकले केही उपयोगी सिक्दैन, र प्रमाणीकरण गर्ने घटकले आफूलाई आवश्यक सबै सिक्छ।

OpenVPN समुदायले यसलाई स्पष्ट रूपमा अभिलेख गर्छ: auth-user-pass-verify ले पेस गरिएका प्रमाणहरू प्रमाणीकरण स्क्रिप्ट वा प्लगइनलाई सुम्पन्छ। यो घटकहरूबीचको जानाजानी हस्तान्तरण हो, र यो नामित पक्षका रूपमा विश्वास मोडेलमा पर्छ।

प्रमाणितकर्ताले पासवर्ड देख्छ

कुनै घटकले प्रमाणीकरणका लागि पासवर्ड प्राप्त गरेपछि, रहस्य भित्रै रहन्छ कि भन्ने त्यो घटकको पहुँच नियन्त्रण, लगिङ र कोड गुणस्तरले निर्धारण गर्छ। प्रमाण लगमा लेख्ने स्क्रिप्ट, वा त्यसलाई क्यासमा राख्ने प्लगइनले प्रोटोकलले सिर्जना गरेभन्दा धेरै ठूलो जोखिम सिर्जना गर्छ। पहुँच टनेलमा होइन, वास्तुकला र भूमिकामा निर्भर हुन्छ, त्यसैले प्रमाणितकर्ता नियन्त्रण गर्ने सेवा मालिक मूल्याङ्कनमा पर्छ।

फरक विधिले फरक सामग्री उजागर गर्छ। प्रमाणपत्रद्वारा प्रमाणीकरणले निजी कुञ्जी नपठाई प्रमाणित गर्छ, र महासंघ प्रवाहले पासवर्ड पहिचान प्रदायकसँग राख्दै VPN लाई सीमित दाबी जारी गर्न सक्छ। ती डिजाइनले वृत्त साँघुरो गर्छन्; तीमध्ये कुनैले पनि प्रत्येक विश्वसनीय पक्ष हटाउँदैन।

भण्डारण गरिएका ह्यासले फरक चरणको रक्षा गर्छन्

NIST को मार्गदर्शनले संरक्षित यात्रा र प्रतिरोधी प्रमाणितकर्ता भण्डारणलाई अलग गर्छ। नुन र खर्चयुक्त ह्यासिङ योजनाले भण्डारित-प्रमाणितकर्ता खतरालाई सम्बोधन गर्छ, जुन डेटाबेस चुहिएपछि पछि हुने कुरा हो। तिनीहरूले तुलना गर्न इनपुट प्राप्त गर्नैपर्ने रनटाइम घटकका लागि केही गर्दैनन्। मार्गदर्शनलाई रनटाइम गोपनीयताको वाचा गरेझैँ पढ्नु वर्गको गल्ती हो।

त्यसैले राम्ररी ह्यास गरिएको पासवर्ड भण्डार र खुला प्रमाणीकरण स्क्रिप्ट विरोधाभास बिना एउटै उत्पादनमा सहअस्तित्वमा रहन सक्छन्।

वृत्त साँघुरो गर्ने विधि छनोट गर्ने

यदि गेटवेले कहिल्यै पुनः प्रयोगयोग्य पासवर्ड नपाओस् भन्ने आवश्यकता हो भने, त्यो साँच्चै ग्यारेन्टी गर्ने विधि छान्नुहोस्; डेटा साइफर बदल्नाले त्यो गुण सिर्जना हुँदैन। VPN सर्भरको प्रमाणपत्र प्रमाणित गर्दा तपाईं कुन समकक्षसम्म पुग्नुभयो भन्ने थाहा हुन्छ; त्यो समकक्षले पछि प्रमाणहरूसँग कसरी व्यवहार गर्छ भन्ने केही थाहा हुँदैन। सर्भर प्रमाणीकरण राख्नुहोस्, प्रत्येक सेवाका लागि फरक प्रमाण प्रयोग गर्नुहोस्, र संस्थाको समर्थित पहिचान प्रवाह पछ्याउनुहोस्।

पासवर्ड प्राप्त गर्ने पक्ष, त्यसको प्रमाणीकरण गर्ने पक्ष र त्यो राखिने ढाँचा अभिलेख गर्नुहोस्। ती तीन उत्तर जडान प्रोफाइलको छेउमा पर्छन्, किनकि तिनीहरू कुनै पनि विशेष टनेलभन्दा लामो बाँच्छन्।

उपयोगी प्रश्न पासवर्ड इन्क्रिप्ट भएको हो कि होइन भन्ने होइन, बरु त्यो कसबाट लुकाइएको छ, कुन घटकले त्यो प्राप्त गर्छ र पछि कुन ढाँचा टिक्छ भन्ने हो।

सम्बन्धित लेखहरू