LDAP - "प्रमाणीकरण" एक एंटीपैटर्न है

आज, किसी भी संगठन के पास इस संगठन के उपयोगकर्ताओं से भरा एक LDAP निर्देशिका है। यदि आप बारीकी से देखते हैं, तो आपको एक या अधिक एप्लिकेशन मिलेंगे जो "प्रमाणीकरण" के लिए एक ही निर्देशिका का उपयोग करते हैं। और उद्धरण चिह्न यहां आकस्मिक नहीं हैं, क्योंकि LDAP एक निर्देशिका एक्सेस प्रोटोकॉल है जिसे निर्देशिका सेवा को पढ़ने, लिखने और खोजने के लिए डिज़ाइन किया गया है। यह एक प्रमाणीकरण प्रोटोकॉल नहीं है। "LDAP प्रमाणीकरण" शब्द, बल्कि प्रोटोकॉल के उस हिस्से (बाइंड ऑपरेशन) को संदर्भित करता है, जो यह निर्धारित करता है कि आप कौन हैं और निर्देशिका जानकारी के लिए आपके पास कौन से अधिकार हैं।

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

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

यह समझने के लिए कि ये भेद्यताएं क्या हैं, आपको पहले यह समझना होगा कि LDAP प्रमाणीकरण कैसे काम करता है।

कैसे LDAP प्रमाणीकरण काम करता है

निम्नलिखित स्थिति की कल्पना करें (यह वास्तविकता से बहुत दूर है, लेकिन यह सार को पूरी तरह से बताता है)।

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

रसद के साथ समस्याओं के अलावा, यह स्थिति अन्य मुद्दों से भरी हुई है। क्या होगा अगर एक बेईमान समीक्षक ने मेरी कुंजी की एक प्रति बनाई? या क्या उसने लंबे समय तक बिना चाबी के चाबी छोड़ दी, और किसी और ने? क्या होगा अगर परीक्षक पर हमला किया गया और मेरी कुंजी ले ली गई? जब मैं अपने अपार्टमेंट की चाबी किसी अजनबी को देता हूं, तो मैं उसकी शालीनता और अपनी सुरक्षा के बारे में सुनिश्चित नहीं हो सकता।

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

एलडीएपी दुनिया में, हमें अभी भी अपनी ओर से दरवाजा खोलने के लिए अपनी चाबियाँ पास करनी होंगी। हम अपना पासवर्ड किसी तीसरे पक्ष को स्थानांतरित करते हैं, और वह इसके साथ LDAP सर्वर को घुसाने की कोशिश कर रहा है। यदि वह पहुंच प्राप्त करने का प्रबंधन करता है, तो हम यह सुनिश्चित नहीं कर सकते कि हमारी साख से समझौता नहीं किया गया है। इस मामले में, हमलावर को न केवल एलडीएपी दरवाजे को अनलॉक करने की क्षमता मिलेगी, बल्कि किसी भी एप्लिकेशन तक पहुंच भी होगी जो समान क्रेडिट का उपयोग करता है।

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

प्रमाणीकरण प्रणाली के रूप में LDAP के नुकसान

2007 में, शुमोन हैक ने एक विज्ञान कथा लेख ( LDAP कमजोरियों को एक केंद्रीय प्रमाणीकरण प्रणाली के रूप में ) जारी किया, जिसमें वह LDAP को प्रमाणीकरण प्रणाली के रूप में उपयोग करते समय तीन विशिष्ट समस्याओं का वर्णन करता है।

1. क्रेडेंशियल को संभालने के लिए एप्लिकेशन संभवतः पर्याप्त सुरक्षित नहीं है

लेखक इस बात पर जोर देता है कि प्रमाणीकरण सर्वर के एक छोटे से सेट को हमले से बचाना बड़ी संख्या में एप्लिकेशन सर्वरों की रक्षा करने की तुलना में बहुत आसान है।

अधिकांश भाग के लिए, प्रमाणीकरण सर्वर, एक नियम के रूप में, सूचना सुरक्षा के क्षेत्र में महत्वपूर्ण अनुभव वाले विशेषज्ञों की नज़दीकी निगरानी में हैं।

दूसरी ओर, एप्लिकेशन सर्वर में सुरक्षा का पूरी तरह से अलग स्तर होता है और इससे समझौता होने का खतरा अधिक होता है। वे कम सुरक्षित हैं, अधिक जटिल सॉफ्टवेयर स्टैक्स के साथ काम करते हैं, और कमजोरियों की अधिक संभावना है। और अधिक बार वे ऐसे लोगों द्वारा प्रबंधित किए जाते हैं जिन्हें सुरक्षा का गहरा ज्ञान नहीं है। सही सुरक्षा प्रणाली का निर्माण एक जटिल प्रक्रिया है जिसमें गलती करना बहुत आसान है।

समस्या यह है कि यदि एक एप्लिकेशन सर्वर से समझौता किया जाता है, तो हमले के दौरान उनके मालिकों द्वारा उपयोग किए जाने वाले सभी क्रेडेंशियल्स भी समझौता किए जाते हैं। प्रमाणीकरण के लिए उसी LDAP निर्देशिका का उपयोग करने वाली कोई भी अन्य प्रणाली जोखिम में है।

2. LDAP सर्वर क्रेडेंशियल प्राप्त करने के लिए उपयोग किए जाने वाले प्रमाणीकरण तंत्र को सुरक्षित नहीं कर सकता है

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

3. उपयोगकर्ता को अपने प्रमाणीकरण रहस्य को तीसरे पक्ष के साथ साझा करने के लिए मजबूर किया जाता है

उपयोगकर्ता पासवर्ड या प्रमाणीकरण रहस्य एक रहस्य बना रहना चाहिए। यह केवल उपयोगकर्ता और प्रमाणीकरण प्रणाली के लिए जाना जाना चाहिए। LDAP प्रमाणीकरण का उपयोग करते समय, उपयोगकर्ता को अपने रहस्य को तीसरे पक्ष के साथ साझा करने के लिए मजबूर किया जाता है ताकि वह फिर इस रहस्य का उपयोग उपयोगकर्ता की ओर से LDAP निर्देशिका के साथ बातचीत करने के लिए कर सके।

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

शूमोन हुक के बिंदुओं के लिए, मैं अपने स्वयं के अनुभव के आधार पर LDAP प्रमाणीकरण की कई बारीकियों का विवरण जोड़ूंगा। सबसे पहले, विषय सक्रिय निर्देशिका के उपयोग की चिंता करता है।

4. कई डेवलपर्स इसे सही ढंग से उपयोग करने के लिए LDAP तंत्र के बारे में पर्याप्त नहीं जानते हैं

मेरे पिछले ब्लॉग पोस्टों में से एक यह बताता है कि कैसे अनाम और अनधिकृत बाइंड ने एप्लिकेशन डेवलपर्स को आउटवेट करने की अनुमति दी और अनधिकृत उपयोगकर्ताओं को छोड़ने के लिए मजबूर किया। प्रमाणीकरण के बिना एक बाइंड ऑपरेशन करने की क्षमता प्रोटोकॉल की सूक्ष्मताओं में से एक है जो कि सबसे अनुभवी LDAP विशेषज्ञों को भी पता नहीं है।

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

5. एप्लिकेशन एडमिनिस्ट्रेटर अक्सर LDAP क्लाइंट को सही तरीके से कॉन्फ़िगर नहीं करते हैं

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

मिसकॉन्फ़िगरेशन की भयावहता के उदाहरण निम्न हैं।

• अनुप्रयोगों में हार्डकोडिंग डीएन या एक बाँध ऑपरेशन में डीएन का उपयोग करना। किसी निर्देशिका के अंदर ऑब्जेक्ट्स का नाम बदलने या आगे बढ़ने पर लगातार परेशानी होती है, और सभी क्योंकि किसी ने हार्डकोड डीएन। (सक्रिय निर्देशिका के साथ सरल बाइंड ऑपरेशन करने वालों के लिए ध्यान दें: DN का उपयोग करने की कोई आवश्यकता नहीं है। सक्रिय निर्देशिका वैकल्पिक DN प्रारूप भी प्रदान करती है जो पारंपरिक प्रारूप का उपयोग करने से अधिक विश्वसनीय हैं।
• बाइंड ऑपरेशन के लिए, एक सेवा खाते का उपयोग नहीं किया जाता है, लेकिन डेवलपर या व्यवस्थापक का एक व्यक्तिगत खाता (कल्पना करें कि जब खाता स्वामी कंपनी छोड़ देता है तो क्या होगा)।
• 389 पोर्ट करने के लिए स्पष्ट पाठ में पासवर्ड भेजना।
• टीएलएस (पोर्ट 636) का उपयोग करके एडी से कनेक्ट करते समय ऐसे अनुप्रयोग हैं जहां "वैध प्रमाणपत्र" चेकबॉक्स की आवश्यकता नहीं है। यह आम तौर पर स्वीकार्य क्यों है? मैं इसकी प्रामाणिकता के बारे में आश्वस्त हुए बिना पासवर्ड को किसी तृतीय-पक्ष सेवा में कैसे पारित कर सकता हूं?

LDAP क्लाइंट काम करना आसान है। लेकिन सिर्फ यह तथ्य कि यह काम करता है इसका मतलब यह नहीं है कि कॉन्फ़िगरेशन सही है।

6. LDAP प्रमाणीकरण और आधुनिक प्रमाणीकरण सेवाएं परस्पर अनन्य हैं

प्रमाणीकरण के लिए LDAP का उपयोग करने वाले एप्लिकेशन को हमेशा उपयोगकर्ता नाम और पासवर्ड पर निर्भर रहना होगा। आधुनिक तकनीकों को लागू करने की कोशिश करना, जैसे कि बहु-कारक प्रमाणीकरण और एकल साइन-ऑन, लगभग असंभव है (जब तक कि आप अपनी खुद की तकनीकों को लागू नहीं करने जा रहे हैं, जो अपने आप में एक बुरा विचार है)। FIDO एलायंस पासवर्ड को अतीत का अवशेष बनाने के लिए प्रतिबद्ध है, और हर एप्लिकेशन जो LDAP प्रमाणीकरण का उपयोग करता है, वह पासवर्ड-मुक्त नीति के लिए एक बाधा होगी।

विकल्प क्या हैं?

आज वेब एप्लिकेशन LDAP प्रमाणीकरण के बिना वास्तव में कर सकते हैं। कई महान वेब प्रमाणीकरण प्रोटोकॉल हैं, जैसे एसएएमएल, डब्ल्यूएस-फेडरेशन और ओपनआईडी कनेक्ट, जिन्हें तीसरे पक्ष के अनुप्रयोगों के साथ काम करने के लिए उपयोगकर्ता क्रेडेंशियल्स की आवश्यकता नहीं है। अनगिनत उत्पाद सक्रिय निर्देशिका महासंघ सेवा (विंडोज सर्वर में निर्मित) या Microsoft Azure AD, Okta, Ping, और अन्य जैसे तृतीय-पक्ष सेवाएँ सहित इन सेवाओं को प्रदान करते हैं। यदि आपके संगठन में एक फ़ेडरेटेड IdP नहीं है, तो सबसे पहले इसे लागू करना है।

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

आधुनिक प्रमाणीकरण प्रोटोकॉल का समर्थन करने वाले "मोटी क्लाइंट" के साथ डेस्कटॉप अनुप्रयोगों की संख्या बढ़ रही है, और यह वास्तव में एक खुशी की प्रवृत्ति है। ये अनुप्रयोग आमतौर पर LDAP प्रमाणीकरण का एक गढ़ थे। एसडीके की बढ़ती संख्या, जैसे कि माइक्रोसॉफ्ट ऑथेंटिकेशन लाइब्रेरी (MSAL), डेवलपर्स के लिए अपने मोबाइल और डेस्कटॉप अनुप्रयोगों के लिए आधुनिक प्रमाणीकरण सेवाओं के लिए समर्थन जोड़ना आसान बनाता है।

अंततः, यह पहचानने योग्य है कि आज की वास्तविकता में, सभी अनुप्रयोग आधुनिक प्रमाणीकरण प्रोटोकॉल का समर्थन नहीं करते हैं, और कभी भी नहीं हो सकते हैं। LDAP प्रमाणीकरण पर पूर्ण प्रतिबंध लागू करना संभवत: किसी भी संगठन में संभव नहीं है। हालांकि, किसी भी तरह से एलडीएपी प्रमाणीकरण को संगठन के भीतर प्रोत्साहित नहीं किया जाना चाहिए। एलडीएपी के उपयोग को अन्य विकल्पों की अनुपस्थिति में ही माना जाना चाहिए।