ডেস্কটপ অ্যাপ্লিকেশনটির জন্য 'অ্যাডমিন পাসওয়ার্ড' সরবরাহের জন্য কিছু সম্ভাব্য বিকল্পগুলি কী কী?

Question

আমি বর্তমানে এক দশকেরও বেশি সময় ধরে আমার সংস্থায় ব্যবহৃত একটি সফটওয়্যারটির টুকরোটি পরিচালনা এবং পুনরায় ফ্যাক্টর করছি। এই অ্যাপ্লিকেশনটির অন্যতম উপাদান হ'ল অ্যাডমিন বা পাওয়ার-ব্যবহারকারী মোড যা কিছু অতিরিক্ত / অভ্যন্তরীণ ইনপুট এর পাশাপাশি ইনপুট সীমা বন্ধ করার ক্ষমতা সরবরাহ করে turn

Modeতিহাসিকভাবে এই মোডটি চালু করা হয়েছে উইন্ডোজ সিস্টেম ডিরেক্টরিতে একটি নির্দিষ্ট জায়গায় নির্দিষ্ট নামকরণ করা ফাইল (যা উভয়ই প্রয়োগের মধ্যে হার্ড কোডড ছিল), ফাইলটির নাম রাখা হয়েছে 'কিছু.ডিএলএল', যদিও এটি খালি ছিল though ASCII ফাইল এবং একটি dll নয়।

সুতরাং আমি সম্প্রতি কিছু কোড এবং একটি সামান্য মডেল ফর্ম যুক্ত করেছি যা ব্যবহারকারীকে এই কার্যকারিতাটি চালু করতে প্রশাসকের পাসওয়ার্ড প্রবেশ করতে দেয়। এটি একটি সেট পাসওয়ার্ড, ব্যবহারকারী নির্দিষ্ট নয়। যখন সঠিক পাসওয়ার্ড প্রবেশ করানো হয়, এটি অ্যাপ্লিকেশন রুট ডিরেক্টরিতে একটি 'কী ফাইল' তৈরি করে একই জিনিসটি সাজায় যাতে ফাইলটি উপস্থিত থাকলে প্রোগ্রামটি অ্যাডমিন মোডে শুরু করতে পারে।

এখন বিভাগটির ব্যবস্থাপক যে এই সফ্টওয়্যারটি বেশিরভাগ ক্ষেত্রেই সেই ধারণাটি এত পছন্দ করে না। তিনি মনে করেন যে আমাদের যদি কেবল একটি সাধারণ, প্রিসেট পাসওয়ার্ড থাকে যা এটি সহজেই 'আউট' হয়ে যায় এবং তিনি অনভিজ্ঞ ব্যবহারকারীদের এই অতিরিক্ত বৈশিষ্ট্যগুলি অ্যাক্সেস করতে চান না।

সুতরাং আমার প্রশ্নটি হল, এই ধরণের অ্যাক্সেস সরবরাহের জন্য আরও কিছু পদ্ধতি কী রয়েছে যা কিছুটা বেশি সুরক্ষিত হবে? এই সফ্টওয়্যারটি রক্ষণাবেক্ষণ এবং পরিচালনা করার ক্ষেত্রে এটি ঠিক আমার পক্ষে ঠিক আছে, সুতরাং প্রায় সম্পূর্ণরূপে বিল্ট বা স্বয়ংক্রিয়ভাবে তৈরি নয় এমন কোনও কিছুই সহায়তা করবে না (যেমন 'লাইসেন্স কীগুলির জন্য অনুরোধ পাঠানো বা এর অনুরূপ কিছু) something

দ্রষ্টব্য: এই অ্যাপ্লিকেশনটি 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

এটি একটি খুব ভাল উত্তর, এবং আমি অবশ্যই এই এবং অন্যান্য প্রকল্পগুলির জন্য মনে রাখব। তবে আসল সমস্যাটি হ'ল আমাদের সংস্থার বাইরে এই প্রোগ্রামটির ব্যবহারকারীরা। আমরা এটি আমাদের বোন সংস্থাগুলি এবং কয়েকটি বহিরাগত, তৃতীয় পক্ষের ব্যবহারকারীদের জন্য সরবরাহ করি। আমি আসলে এই মুহূর্তে ভাবছি যে আমাদের নেটওয়ার্কের বাইরের লোকদের জন্য এই বৈশিষ্ট্যগুলি সম্পূর্ণরূপে অক্ষম করা এবং অভ্যন্তরীণ উদ্দেশ্যে আপনার পরামর্শটি ব্যবহার করা ভাল be

— অ্যান্টনি

Answer 2

ম্যানেজার পাসওয়ার্ড আউট করার বিষয়ে ঠিক আছে । এটি যদি হয় না তবে কখন হয় matter

যেহেতু অ্যাক্টিভ ডিরেক্টরি কোনও ব্যবহারকারীর জন্য বিকল্প নয়, আপনি উইন্ডোজ লগইন নামের একটি তালিকা সহ স্বাক্ষরিত পাঠ্য ফাইল তৈরি করতে পারেন যা সুপার ব্যবহারকারীর অ্যাক্সেসের অনুমতিপ্রাপ্ত। এটি ধরে নেওয়া হয় যে লোকেরা কম্পিউটার বা লগইন ভাগ করে নি।

ব্যবহারকারীর নামগুলি সহজেই বিতরণ করা একটি টেক্সট ফাইলে যাবে যা অ্যাপ্লিকেশনটির ফোল্ডারে রাখা হবে। গুরুত্বপূর্ণ অংশটি হ'ল ব্যবহারকারীর নামের তালিকায় সই করা। এটি খুব সহজ রাখুন। প্রতি সারি এক ব্যবহারকারীর নাম এবং হ্যাশটি শেষ লাইনে রাখুন। আপনার প্রোগ্রাম বাইনারি কোনও ধরণের গোপন কী এম্বেড করুন এবং ব্যবহারকারীর নাম দিয়ে এটি হ্যাশ। গোপন কীটি লোকেদের ফাইলটি সংশোধন করতে এবং তারপরে হ্যাশগুলি নিজেরাই গণনা করা থেকে বিরত করবে (যা সম্ভবত এটি সুদূরপ্রসারিত)।

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

অবশ্যই এটি অনুমোদিত ব্যক্তির তালিকার প্রশাসক হিসাবে কোথাও কাউকে কাজ করার প্রয়োজন। প্রশাসকের একটি প্রোগ্রাম থাকা উচিত (আপনার দ্বারা লিখিত!) যা ফাইল এবং হ্যাশ উত্পন্ন করে। অন্য কিছু না হলে এটি কেবল ব্যবহারকারীর নামের একটি পাঠ্য ফাইল নিতে পারে এবং হ্যাশ যুক্ত করতে পারে।

পুঙ্খানুপুঙ্খভাবে হওয়ার আগ্রহের সাথে, যে কেউ অ্যাক্সেস প্রত্যাহার করা হয়েছে সে ফাইলটির অনুলিপিটি ধরে রাখতে পারে যার মধ্যে এখনও তাদের লগইন নাম রয়েছে। যখনই তারা অ্যাক্সেস চেয়েছিল, তারা কেবল তাদের অনুলিপি ঠিক জায়গায় রাখতে পারত। যদিও উদ্বিগ্ন হওয়ার মতো কিছু নয়।

Answer 3

যেহেতু অ্যাক্টিভ ডিরেক্টরি কোনও বিকল্প নয়, আমি বর্তমান তারিখটি হ্যাশ করব। সর্বাধিক এনট্রপি সহ প্রথম (মাসের দিন) এবং সর্বনিম্ন এনট্রপি সহ গত (বছর) সহ উপাদানগুলি ব্যবহার করুন। যদি প্রয়োজন হয় তবে একটি ডোমেন-নির্দিষ্ট লবণ যুক্ত করুন (গ্রাহকের আইডি, কোম্পানির নাম ইত্যাদি যেহেতু এটি আপনার সংস্থার বাইরে ব্যবহার করা হয়)। এটি প্রতিদিন একটি খুব আলাদা পাসওয়ার্ড তৈরি করা উচিত যা শেষ ব্যবহারকারীদের পক্ষে অনুমান করা কার্যত অসম্ভব এবং সফ্টওয়্যার ব্যবহার করে এমন বিভিন্ন সংস্থার পক্ষে এটি আলাদা হতে পারে।

এটি মূলত একটি মুরগি এবং ডিমের সমস্যা কারণ সফ্টওয়্যারটি বাড়িতে ফোন করেই ব্যবহারকারীকে প্রমাণীকরণ করতে সক্ষম হয়। সুতরাং একটি সত্যই অস্পষ্ট ক্র্যাকিং মেকানিজম দিয়ে একটি ডিম তৈরি করুন: যদিও অস্পষ্টতার মাধ্যমে সুরক্ষা আসল সুরক্ষা নয়, তবে আপনার সমস্যার পরামিতিগুলিই এটিই সেরা।

এটি কোথাও একটি পাঠ্য ফাইল রাখার চেয়েও ভাল: এটি কোনও স্থির পাসওয়ার্ডের চেয়ে ভাল নয় কারণ গোপনীয়তাটি শেষ হয়ে গেলে, শেষ হয়ে যায়।

Answer 4

ব্যবহারের অ্যাক্সেস নিয়ন্ত্রন তালিকা ।

এটি করার দ্রুত এবং নোংরা উপায় হ'ল অ্যাপ্লিকেশন ডিরেক্টরি থেকে সমস্ত অনুমতি সরিয়ে ফেলা (পড়ার অনুমতি সহ), তারপরে অ্যাপ্লিকেশন চালানোর অনুমতিপ্রাপ্ত যে কোনও ব্যবহারকারীর জন্য এই অনুমতিগুলি যুক্ত করুন। অবশ্যই, অনুমতি সহ কোনও ব্যবহারকারী সহজেই অ্যাপ্লিকেশন ডিরেক্টরিটিকে কোনও সর্বজনীন স্থানে অনুলিপি করতে পারতেন, তবে এটি দুর্ঘটনাক্রমে হওয়ার সম্ভাবনা নেই, তবে পাসওয়ার্ড ভাগ করে নেওয়া দুর্ঘটনাক্রমে সহজেই ঘটতে পারে।

অবশ্যই এটি ধরে নেওয়া হয় যে জড়িত কম্পিউটারগুলি সুরক্ষিত (আশা করি সক্রিয় ডিরেক্টরি সহ)।

Comments

যদি জড়িত কম্পিউটারগুলি সক্রিয় ডিরেক্টরি সহ সুরক্ষিত হয় তবে এটি কোনও সুরক্ষা গোষ্ঠীর সদস্যতার মাধ্যমে উন্নত কার্যকারিতা সুরক্ষিত করা সবচেয়ে ভাল। ব্যবহারকারীদের প্রয়োজনীয় ভিত্তিতে গ্রুপে যুক্ত করা যেতে পারে এবং ফাইল সিস্টেমের অনুমতিগুলি প্রাসঙ্গিক নয়

— কেভিন

@ কেভিন: সম্মত আমি ড্যান এর উত্তর যে কভার।

— ব্রায়ান

Answer 5

আমার পছন্দটি @ ড্যানের পরামর্শ অনুসারে - সক্রিয় ডিরেক্টরি ব্যবহার করুন। যদি এটি সম্ভব না হয় তবে সময়ের ভিত্তিতে একটি পাসওয়ার্ড জেনারেটর কার্যকর হতে পারে। অনুরূপ পরিস্থিতিতে, (খুব দূর অতীতের) আমার ব্যবহৃত একটি সংস্থা আমি 9999-MMDD এর জন্য ব্যবহৃত হয়েছিল। কয়েক বছর পরে এটি বেরিয়ে আসে। যদি আপনি এইচএমএম ছুড়ে ফেলেছেন এবং কিছুটা মিশিয়ে দিয়েছেন তবে কেউ বিড়ালটিকে ব্যাগটি বের করার আগে তার মধ্যে থেকে এক বা দু'বছর বের হতে পারে।

আপনি সর্বদা একটি প্রোগ্রাম লিখতে পারেন যা অনুরূপ, তবে আরও জটিল কৌশল ব্যবহার করে পাসওয়ার্ড তৈরি করে। ব্যবহৃত নামটিতে একটি মেশিনের নামও নিক্ষেপ করুন। আপনার ব্যবস্থাপক কেবল সেই মেশিনের জন্য বর্তমান পাসওয়ার্ড পেতে সেই প্রোগ্রামটি চালাতে পারেন। ফাইলটিতে কিছু তথ্য সংরক্ষণ করুন যাতে অন্য মেশিনে অনুলিপি করা হয় বা অন্য কোনও ব্যবহারকারী লগ ইন করা থাকে তবে এটি বৈধ নয় the প্রোগ্রামটি সুরক্ষিত রাখতে আপনার ম্যানেজারের উপর নির্ভর করে এবং যদি বিড়ালটি বেরিয়ে যায় তবে তার দোষ।

এই স্কিমটি সিরপ্টো দৃষ্টিকোণ থেকে দুর্বল এবং অবিশ্বাস্য বলে বিবেচিত হয়, তবে আপনার সমস্যাটির জন্য এটি যথেষ্ট।