डेस्कटॉप एप्लिकेशन के लिए 'व्यवस्थापक पासवर्ड' प्रदान करने के लिए कुछ संभावित विकल्प क्या हैं?

Question

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

ऐतिहासिक रूप से इस मोड को विशेष रूप से नामित फ़ाइल को विंडोज़ सिस्टम डायरेक्टरी (जो दोनों में हार्ड कोड दिया गया था) में डालकर चालू किया गया है, फ़ाइल को 'something.DLL' नाम दिया जा रहा है, भले ही वह खाली थी ASCII फ़ाइल और dll नहीं।

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

अब विभाग के प्रबंधक कि यह सॉफ्टवेयर ज्यादातर उस विचार को पसंद नहीं करता है। वह सोचता है कि अगर हमारे पास बस एक सरल, पूर्व निर्धारित पासवर्ड है कि यह आसानी से 'बाहर निकल जाएगा', और वह अनुभवहीन उपयोगकर्ताओं को उन अतिरिक्त सुविधाओं तक नहीं पहुंचना चाहता है।

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

नोट्स: यह एप्लिकेशन VB.NET (.NET 4.0) में लिखा गया है, और मैं वर्तमान में नया संस्करण होने पर क्लिक-एक बार तैनाती का उपयोग करने की योजना बना रहा हूं।

Comments

किसी को यह निर्णय करना होगा कि कौन से उपयोगकर्ता "अनुभवहीन" हैं और जो नहीं हैं। वह निर्णय कौन करता है? उस फैसले को किसको सिस्टम में डालना है?

— डॉक ब्राउन

Answer 1

यदि आपके पास सक्रिय निर्देशिका है, तो आप सदस्यता के लिए सक्रिय निर्देशिका समूह में परीक्षण कर सकते हैं:

public bool IsInADGroup(string ADGroupName)
    {
        bool result = false;
        List<string> myGroups = new List<string>();

        using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, SystemInformation.UserDomainName))
        {
            using (PrincipalSearchResult<Principal> src = UserPrincipal.FindByIdentity(pc, SystemInformation.UserName).GetGroups(pc))
            {
                src.ToList().ForEach(sr => myGroups.Add(sr.SamAccountName));
            }
        }
        result = myGroups.Contains(ADGroupName);
        return result;
    }

Comments

यह एक बहुत अच्छा जवाब है, और कुछ मैं निश्चित रूप से इस और अन्य परियोजनाओं के लिए ध्यान में रखूंगा। हालाँकि असली मुद्दा हमारी कंपनी के बाहर इस कार्यक्रम के उपयोगकर्ताओं का है। हम इसे अपनी बहन कंपनियों और कुछ बाहरी, 3 पार्टी उपयोगकर्ताओं के लिए प्रदान करते हैं। मैं वास्तव में इस बिंदु पर सोच रहा हूं कि हमारे नेटवर्क के बाहर के लोगों के लिए इन सुविधाओं को पूरी तरह से अक्षम करना और आंतरिक उद्देश्यों के लिए अपने सुझाव का उपयोग करना सबसे अच्छा होगा।

— एंथोनी

Answer 2

पासवर्ड निकलने के बारे में प्रबंधक सही है । यह अगर नहीं की बात है, लेकिन जब।

चूंकि सक्रिय निर्देशिका कुछ उपयोगकर्ताओं के लिए कोई विकल्प नहीं है, इसलिए आप Windows लॉगिन नामों की सूची के साथ एक हस्ताक्षरित पाठ फ़ाइल बना सकते हैं जिसे सुपर उपयोगकर्ता की अनुमति है। यह मानता है कि लोग कंप्यूटर या लॉगिन साझा नहीं कर रहे हैं।

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

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

यह, निश्चित रूप से, किसी को अधिकृत उपयोगकर्ताओं की सूची के व्यवस्थापक के रूप में कार्य करने के लिए कहीं न कहीं आवश्यकता होती है। व्यवस्थापक के पास एक प्रोग्राम होना चाहिए (आपके द्वारा लिखित!) जो फ़ाइल और हैश उत्पन्न करता है। यदि और कुछ नहीं, तो यह केवल उपयोगकर्ता नामों की एक पाठ फ़ाइल ले सकता है और हैश को जोड़ सकता है।

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

Answer 3

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

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

यह एक पाठ फ़ाइल को कहीं रखने से भी बेहतर है: यह एक स्थिर पासवर्ड से बेहतर नहीं है क्योंकि एक बार जब रहस्य निकल जाता है, तो गेम खत्म हो जाता है।

Answer 4

एक्सेस कंट्रोल लिस्ट का उपयोग करें ।

ऐसा करने का त्वरित और गंदा तरीका एप्लिकेशन निर्देशिका (रीड अनुमति सहित) से सभी अनुमतियों को निकालना है, फिर उन उपयोगकर्ताओं के लिए इन अनुमतियों को जोड़ें, जिन्हें एप्लिकेशन चलाने की अनुमति है। बेशक, अनुमति वाला उपयोगकर्ता किसी सार्वजनिक स्थान पर एप्लिकेशन निर्देशिका को आसानी से कॉपी कर सकता है, लेकिन यह आकस्मिक रूप से होने की संभावना नहीं है, जबकि पासवर्ड साझाकरण गलती से हो सकता है।

यह मानते हैं कि इसमें शामिल कंप्यूटर सुरक्षित हैं (उम्मीद है कि सक्रिय निर्देशिका के साथ)।

Comments

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

— केविन

@ केविन: सहमत। मुझे लगता है कि दान का उत्तर कवर करता है।

— ब्रायन

Answer 5

मेरी प्राथमिकता @Dan के अनुसार है - सक्रिय निर्देशिका का उपयोग करें। यदि यह संभव नहीं है, तो समय पर आधारित एक पासवर्ड जनरेटर उपयोगी हो सकता है। इसी तरह की स्थिति में, (बहुत दूर का अतीत) मेरी एक कंपनी जो मैंने 9999-एमएमडीडी के उपयोग के लिए काम की थी। यह कुछ वर्षों के बाद बाहर हो गया। यदि आप hhmm में फेंक दिया और इसे थोड़ा मिलाया तो आपको एक या दो साल मिल सकते हैं, इससे पहले कि कोई बिल्ली को बैग से निकाल दे।

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

इस योजना को सिरिप्टो दृष्टिकोण से कमजोर और अविश्वसनीय माना जाता है, लेकिन आपके पास जो समस्या है, उसके लिए यह पर्याप्त है।