มีทางเลือกอะไรบ้างในการให้ 'รหัสผ่านผู้ดูแลระบบ' สำหรับแอปพลิเคชันเดสก์ท็อป


10

ขณะนี้ฉันกำลังจัดการและแยกส่วนซอฟต์แวร์ที่ใช้ใน บริษัท ของฉันมานานกว่าทศวรรษแล้ว หนึ่งในองค์ประกอบของแอปพลิเคชั่นนี้คือการเรียงลำดับของโหมดผู้ดูแลระบบหรือผู้ใช้ไฟซึ่งมีสิ่งต่าง ๆ เช่นอินพุตเพิ่มเติม / ภายในบางอย่างรวมถึงความสามารถในการปิดการ จำกัด การป้อนข้อมูล

ในอดีตโหมดนี้เปิดใช้งานโดยการวางไฟล์ที่มีชื่อเฉพาะในสถานที่ที่ระบุในไดเรกทอรีระบบ windows (ซึ่งทั้งสองอย่างนั้นถูกเข้ารหัสอย่างหนักในแอปพลิเคชัน) ไฟล์ที่ถูกตั้งชื่อว่า 'something.DLL' แม้ว่ามันจะว่างเปล่า ไฟล์ ASCII ไม่ใช่ dll

ดังนั้นเมื่อเร็ว ๆ นี้ฉันได้เพิ่มรหัสและรูปแบบคำกริยาเล็กน้อยที่อนุญาตให้ผู้ใช้ป้อนรหัสผ่านของผู้ดูแลระบบเพื่อเปิดใช้งานฟังก์ชันนี้ เป็นรหัสผ่านที่ตั้งไว้ไม่ใช่เฉพาะผู้ใช้ เมื่อป้อนรหัสผ่านที่ถูกต้องมันจะเรียงลำดับของสิ่งเดียวกันโดยสร้าง 'ไฟล์สำคัญ' ในไดเรกทอรีรากของแอปพลิเคชันเพื่อให้โปรแกรมสามารถเริ่มต้นในโหมดผู้ดูแลระบบหากมีไฟล์นั้นอยู่

ตอนนี้ผู้จัดการของแผนกที่ส่วนใหญ่ซอฟต์แวร์นี้ไม่ชอบความคิดนั้นมาก เขาคิดว่าถ้าเรามีรหัสผ่านง่าย ๆ ที่ตั้งไว้ล่วงหน้าว่ามันจะ 'ออกไป' ได้อย่างง่ายดายและเขาไม่ต้องการให้ผู้ใช้ที่ไม่มีประสบการณ์เข้าถึงคุณลักษณะพิเศษเหล่านั้น

ดังนั้นคำถามของฉันคือมีวิธีการอื่นใดอีกบ้างที่ให้การเข้าถึงแบบนี้ที่ค่อนข้างปลอดภัยกว่า? มันเป็นเรื่องของฉันเมื่อพูดถึงการบำรุงรักษาและการจัดการซอฟต์แวร์นี้ดังนั้นสิ่งใดก็ตามที่ไม่ได้ติดตั้งภายในหรือโดยอัตโนมัติก็ไม่ได้ช่วยอะไรเลย (เช่นการส่งคำขอสำหรับ 'คีย์ใบอนุญาต' หรือสิ่งที่คล้ายกัน)

หมายเหตุ: แอปพลิเคชันนี้เขียนขึ้นใน VB.NET (.NET 4.0) และขณะนี้ฉันกำลังวางแผนที่จะใช้การปรับใช้แบบคลิกครั้งเดียวเมื่อเสร็จสิ้นเวอร์ชันใหม่


1
บางคนต้องตัดสินใจว่าผู้ใช้คนใดที่ "ไม่มีประสบการณ์" และไม่ใช่คนที่ ใครเป็นคนตัดสินใจ ใครต้องตัดสินใจเรื่องนั้นในระบบ?
Doc Brown

คำตอบ:


13

หากคุณมี Active Directory คุณสามารถทดสอบการเป็นสมาชิกใน Active Directory Group ได้:

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;
    }

นี่เป็นคำตอบที่ดีมากและสิ่งที่ฉันจะจำไว้สำหรับโครงการนี้และอื่น ๆ อย่างไรก็ตามปัญหาที่แท้จริงคือผู้ใช้โปรแกรมนี้นอก บริษัท ของเรา เราให้บริการกับทั้ง บริษัท ในเครือและผู้ใช้ภายนอกซึ่งเป็นบุคคลภายนอก ฉันคิดว่าจริง ๆ แล้ว ณ จุดนี้ว่าจะเป็นการดีที่สุดที่จะปิดการใช้งานคุณสมบัติเหล่านี้อย่างสมบูรณ์สำหรับผู้ที่อยู่นอกเครือข่ายของเราและใช้คำแนะนำของคุณเพื่อวัตถุประสงค์ภายใน
Anthony

5

ผู้จัดการที่ถูกต้องเกี่ยวกับรหัสผ่านการออก มันไม่ได้เป็นเรื่องของถ้า แต่เมื่อ

เนื่องจาก Active Directory ไม่ใช่ตัวเลือกสำหรับผู้ใช้บางรายคุณสามารถสร้างไฟล์ข้อความที่เซ็นชื่อด้วยรายชื่อเข้าสู่ระบบ windows ที่ได้รับอนุญาตให้เข้าถึงผู้ใช้ขั้นสูง นี่ถือว่าคนไม่ได้แชร์คอมพิวเตอร์หรือเข้าสู่ระบบ

ชื่อผู้ใช้จะอยู่ในไฟล์ข้อความที่กระจายง่ายซึ่งจะอยู่ในโฟลเดอร์ของแอปพลิเคชัน ส่วนที่สำคัญคือการลงชื่อในรายชื่อผู้ใช้ ทำให้มันง่ายมาก ชื่อผู้ใช้หนึ่งชื่อต่อแถวและใส่แฮชบนบรรทัดสุดท้าย ฝังคีย์ลับบางอย่างในไบนารีโปรแกรมของคุณและแฮชมันด้วยชื่อผู้ใช้ รหัสลับจะป้องกันไม่ให้ผู้อื่นแก้ไขไฟล์และคำนวณแฮชด้วยตนเอง (ซึ่งอาจเรียกได้ว่าเริ่มต้นด้วย)

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

แน่นอนว่าสิ่งนี้ต้องการใครสักคนที่จะทำหน้าที่เป็นผู้ดูแลรายการของผู้ใช้ที่ได้รับอนุญาต ผู้ดูแลระบบควรมีโปรแกรม (เขียนโดยคุณ!) ที่สร้างไฟล์และแฮช หากไม่มีอะไรอื่นก็สามารถนำไฟล์ข้อความของชื่อผู้ใช้และเพิ่มแฮช

เพื่อประโยชน์ในการเป็นคนที่ถูกเพิกถอนการเข้าถึงสามารถคว้าสำเนาของไฟล์ที่ยังคงมีชื่อเข้าสู่ระบบของมัน เมื่อใดก็ตามที่พวกเขาต้องการเข้าถึงพวกเขาก็สามารถวางสำเนาของพวกเขาในสถานที่ อาจไม่ใช่สิ่งที่ต้องกังวลเกี่ยวกับ


3

เนื่องจาก Active Directory ไม่ใช่ตัวเลือกฉันจะแฮชวันที่ปัจจุบัน ใช้องค์ประกอบที่มีเอนโทรปีมากที่สุด (วันที่ของเดือน) และองค์ประกอบที่มีเอนโทรปีน้อยที่สุด (ปี) ถ้าจำเป็นให้เพิ่มเกลือเฉพาะโดเมน (รหัสลูกค้าชื่อ บริษัท ฯลฯ เนื่องจากถูกใช้นอก บริษัท ของคุณ) รหัสผ่านนี้ควรสร้างรหัสผ่านที่แตกต่างกันมากในแต่ละวันซึ่งเป็นไปไม่ได้ที่ผู้ใช้จะคาดเดาได้และอาจแตกต่างกันไปสำหรับ บริษัท ต่าง ๆ ที่ใช้ซอฟต์แวร์

นี่เป็นปัญหาไก่และไข่เนื่องจากซอฟต์แวร์จำเป็นต้องสามารถรับรองความถูกต้องของผู้ใช้โดยไม่ต้องโทรศัพท์กลับบ้าน ดังนั้นทำไข่ด้วยกลไกการแตกร้าวที่คลุมเครือจริงๆ: ในขณะที่ความปลอดภัยผ่านความสับสนนั้นไม่ใช่ความปลอดภัยที่แท้จริงนี่คือสิ่งที่ดีที่สุดที่คุณได้รับพารามิเตอร์ของปัญหาของคุณ

นอกจากนี้ยังดีกว่าการวางไฟล์ข้อความไว้ที่อื่น: นั่นไม่ดีไปกว่ารหัสผ่านแบบคงที่เพราะเมื่อความลับหายไป


0

ใช้รายการควบคุมการเข้าถึง

วิธีที่รวดเร็วและสกปรกในการทำเช่นนี้คือการลบสิทธิ์ทั้งหมดออกจากไดเรกทอรีแอปพลิเคชัน (รวมถึงสิทธิ์ในการอ่าน) จากนั้นเพิ่มสิทธิ์เหล่านี้สำหรับผู้ใช้ที่ได้รับอนุญาตให้เรียกใช้แอปพลิเคชัน แน่นอนผู้ใช้ที่ได้รับอนุญาตสามารถคัดลอกไดเรกทอรีแอปพลิเคชันไปยังสถานที่สาธารณะได้อย่างง่ายดาย แต่ไม่น่าจะเกิดขึ้นโดยไม่ตั้งใจขณะที่การแชร์รหัสผ่านอาจเกิดขึ้นได้โดยไม่ตั้งใจ

แน่นอนว่าคอมพิวเตอร์ที่เกี่ยวข้องมีความปลอดภัย (หวังว่าจะมีไดเรกทอรีที่ใช้งานอยู่)


หากคอมพิวเตอร์ที่เกี่ยวข้องปลอดภัยด้วยไดเรกทอรีที่ใช้งานอยู่อาจเป็นการดีที่สุดที่จะรักษาความปลอดภัยของฟังก์ชันขั้นสูงโดยการเป็นสมาชิกของกลุ่มความปลอดภัย ผู้ใช้สามารถเพิ่มลงในกลุ่มได้ตามต้องการและการอนุญาตระบบไฟล์ไม่เกี่ยวข้อง
Kevin

@ เควิน: เห็นด้วย ฉันคิดว่าคำตอบของแดนนั้นครอบคลุม
Brian

0

การตั้งค่าของฉันเป็นที่แนะนำ @Dan - ใช้ไดเรกทอรีที่ใช้งานอยู่ หากเป็นไปไม่ได้ตัวสร้างรหัสผ่านตามเวลาจะมีประโยชน์ ในสถานการณ์ที่คล้ายกัน (ที่ผ่านมาอันไกลโพ้น) บริษัท ของฉันที่ฉันใช้เพื่อใช้งาน 9999-MMDD เรื่องนี้ออกไปหลังจากสองสามปี หากคุณขว้าง hhmm และผสมมันเข้าด้วยกันคุณอาจได้ปีหรือสองปีก่อนที่ใครบางคนจะปล่อยแมวออกจากกระเป๋า

คุณสามารถเขียนโปรแกรมที่สร้างรหัสผ่านโดยใช้กลยุทธ์ที่คล้ายคลึงกัน แต่มีความซับซ้อนมากขึ้น โยนชื่อเครื่องจักรที่ใช้แล้วด้วยเช่นกัน ผู้จัดการคุณสามารถรันโปรแกรมนั้นเพื่อรับรหัสผ่านปัจจุบันสำหรับเครื่องนั้น เก็บข้อมูลบางอย่างไว้ในไฟล์ดังนั้นจึงไม่ถูกต้องหากคัดลอกไปยังเครื่องอื่นหรือหากผู้ใช้คนอื่นลงชื่อเข้าใช้แล้วมันขึ้นอยู่กับคุณแล้วว่าผู้จัดการของคุณจะรักษาโปรแกรมให้ปลอดภัยและถ้าแมวออกมา

แบบแผนนี้ถือว่าอ่อนแอและไม่น่าเชื่อถือจากมุมมองของ cyrpto แต่ก็เพียงพอสำหรับปัญหาที่คุณมี

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.