दो पासवर्ड प्रॉम्प्ट MFA नहीं हैं: VPN लॉगिन क्या सत्यापित करता है

लॉगिन पेज पहले पासवर्ड माँगता है, फिर दूसरा रहस्य, और तैनाती को तुरंत बहु-कारक बताया जाने लगता है। कभी-कभी ऐसा होता भी है। अक्सर यह एक ही कारक होता है जो दो बार इकट्ठा किया गया, क्योंकि दोनों मान वही जानकारी हैं जो उसी व्यक्ति ने उसी स्मृति या उसी नोट से टाइप की। मज़बूत टनल सिफर इसे नहीं बदलता, और उत्पाद के नाम में „सुरक्षित“ शब्द भी नहीं।

दावे को तंत्र से अलग करने के लिए एक ही सवाल चाहिए: हर चरण क्या और किसके सामने साबित करता है?

कारक एक प्रमाण है, फ़ील्ड नहीं

बहु-कारक प्रमाणीकरण का अर्थ है कि उसी खाते के लिए एक से अधिक अलग प्रकार के प्रमाण सत्यापित किए जाते हैं: कुछ जो उपयोगकर्ता जानता है, कुछ जो उसके पास है, कुछ जो वह है। दो फ़ील्ड जो दोनों एक याद रखी गई शृंखला इकट्ठा करते हैं, एक ही प्रकार का प्रमाण हैं जो दो बार माँगा गया। यह उपयोगी नियंत्रण हो सकता है, क्योंकि दो स्वतंत्र रहस्यों का अनुमान लगाना एक से कठिन है, पर यह वह नहीं है जो शब्द बताता है और जोखिम आकलन में इसे ऐसा नहीं गिना जाना चाहिए।

सत्यापन पक्ष उतना ही ज़रूरी है जितना संग्रह पक्ष. किसी डिवाइस पर बना कोड उस डिवाइस पर नियंत्रण तभी साबित करता है जब सर्वर उसे इस खाते से जुड़े रहस्य के विरुद्ध जाँचे और पुनरावृत्तियाँ अस्वीकार करे। साझा कोड जो सबके लिए काम करे, बिना सीमा वाला कोड, या ऐसे डिवाइस पर स्वीकृत अनुरोध जो कभी न दिखाए कि क्या स्वीकृत हो रहा है — ये सब लेबल के संकेत से कमज़ोर हैं।

इसलिए जब कोई पूछे कि VPN में MFA है या नहीं, तो पूछें कि दूसरा चरण क्या साबित करता है और सर्वर उसे कैसे जोड़ता है। अगर जवाब „उसी निर्देशिका से दूसरा पासवर्ड“ है, तो आपके पास एक कारक और नीति पर बातचीत है, दूसरा कारक नहीं।

प्रमाणपत्र के मामले को पढ़ना चाहिए, मानना नहीं

क्लाइंट प्रमाणपत्र के साथ पासवर्ड दो कारक लगते हैं, और हो भी सकते हैं: प्रमाणपत्र किसी भंडार या टोकन पर रखा जाता है, और पासवर्ड याद रखा जाता है। यह एक भी हो सकता है, अगर प्रमाणपत्र फ़ाइल सहेजे गए पासवर्ड वाली उसी प्रोफ़ाइल निर्देशिका में असुरक्षित पड़ी हो, या अगर प्रमाणपत्र ऐसे डिवाइस को जारी किया गया हो जिसे कई लोग बिना व्यक्तिगत जवाबदेही के साझा करते हैं।

तय करने वाला सवाल यह है कि प्रमाणपत्र किसकी या किस चीज़ की पहचान करता है। डिवाइस प्रमाणपत्र साबित करता है कि कोई प्रबंधित मशीन मौजूद है। उपयोगकर्ता प्रमाणपत्र किसी पहचान को साबित करता है। अगर तैनाती हर लैपटॉप के लिए एक प्रमाणपत्र जारी करे और फिर उसकी मौजूदगी को व्यक्ति का प्रमाण माने, तो दूसरा कारक चुपचाप ऐसी हार्डवेयर विशेषता बन गया है जो हर वह व्यक्ति विरासत में पाता है जो लैपटॉप थामे हुए है।

इनमें से कोई भी बात प्रमाणपत्रों को बुरा विचार नहीं बनाती। यह डिवाइस आश्वासन और उपयोगकर्ता आश्वासन के बीच के अंतर को लिखने योग्य बनाती है, क्योंकि दोनों अलग सवालों के जवाब देते हैं और ऐसी अनुपालन शीट जो इन्हें एक गिने, वह बढ़ा-चढ़ा कर बताएगी कि क्या सुरक्षित है।

गेटवे पर भरोसा और उपयोगकर्ता पर भरोसा अलग समस्याएँ हैं

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

इसलिए तरीके का चुनाव अनुरोध के शब्दों से ज़्यादा नतीजा बदलता है। किसी व्यक्ति द्वारा टाइप किए गए कोड कोई भी आगे भेज सकता है जो विश्वासप्रद पेज दिखा सके, जबकि प्रमाणीकरण को विशिष्ट मूल और सत्र से जोड़ने वाली क्रिप्टोग्राफ़िक विधियाँ अपनी बनावट से ही इस अग्रेषण का विरोध करती हैं। आपके पास इनमें से कौन-सी है, यह विधि की विशेषता है, संवाद में चरणों की संख्या नहीं।

आपूर्तिकर्ता के समर्थित पंजीकरण और क्लाइंट प्रवाह का पालन करें, पासवर्ड फ़ील्ड पर अतिरिक्त अनुरोध लगाने के बजाय। घर का बना दूसरा चरण आम तौर पर बीच में कहीं उतरता है और उस बंधन के बिना रगड़ जोड़ता है जो कारक को अर्थपूर्ण बनाता है।

पुनर्प्राप्ति दूसरा सामने का दरवाज़ा है

हर मज़बूत लॉगिन के पास प्रमाणक खो जाने पर वापसी का रास्ता होता है, और यही रास्ता आम तौर पर डिज़ाइन का सबसे कमज़ोर बिंदु होता है। अगर सहायता एजेंट किसी दर्ज नंबर पर कॉल के बाद दूसरा कारक रीसेट कर सकता है, तो हमलावर का सबसे सस्ता रास्ता लॉगिन पेज नहीं, सहायता डेस्क है।

पूछें कि प्रतिस्थापन कैसे होता है, कौन इसका अनुमोदन करता है और कौन-से साक्ष्य चाहिए। फिर जाँचें कि बैकअप कोड जैसी पुनर्प्राप्ति सामग्री प्राथमिक क्रेडेंशियल से अलग रखी जाती है, ताकि एक उल्लंघन दोनों न सौंप दे। NIST के डिजिटल पहचान दिशानिर्देश सत्यापक के बंधन और प्रमाणक के जीवनचक्र को आवश्यकता का हिस्सा मानते हैं, बाद का परिचालनिक विचार नहीं।

आकलन में क्या लिखें

कारकों को प्रकार के अनुसार वर्णित करें, नाम लें कि हर एक क्या साबित करता है और बताएँ कि वह खाते से कैसे जुड़ा है। नोट करें कि विधि अग्रेषण का विरोध करती है या नहीं, और पुनर्प्राप्ति पथ का वर्णन लॉगिन जितनी ही सावधानी से करें।

फिर स्पष्ट कहें कि तैनाती उस परिभाषा के अनुसार बहु-कारक है या नहीं। „दो पासवर्ड और एक मशीन प्रमाणपत्र“ एक ईमानदार वाक्य है, और यह पाठक को „हाँ“ कहने वाले चेकबॉक्स से कहीं ज़्यादा बताता है।