Một số lựa chọn thay thế có thể để cung cấp 'Mật khẩu quản trị viên' cho ứng dụng máy tính để bàn là gì?

Tôi hiện đang quản lý và bao thanh toán lại một phần mềm đã được sử dụng tại công ty của tôi trong hơn một thập kỷ nay. Một trong những yếu tố của ứng dụng này là một loại chế độ quản trị viên hoặc người dùng quyền lực cung cấp những thứ như một số đầu vào bổ sung / nội bộ cũng như khả năng tắt các giới hạn đầu vào.

Về mặt lịch sử, chế độ này đã được bật bằng cách đặt một tệp có tên cụ thể vào một vị trí cụ thể trong thư mục hệ thống windows (cả hai đều được mã hóa cứng vào ứng dụng), tệp được đặt tên là 'Something.DLL', mặc dù nó trống Tệp ASCII và không phải là một dll.

Vì vậy, gần đây tôi đã thêm một số mã và một hình thức phương thức nhỏ cho phép người dùng nhập mật khẩu quản trị viên để bật chức năng này. Nó là một mật khẩu được thiết lập, không cụ thể người dùng. Khi nhập mật khẩu chính xác, nó sẽ thực hiện điều tương tự bằng cách tạo một 'tệp chính' trong thư mục gốc của ứng dụng để chương trình có thể bắt đầu ở chế độ quản trị nếu có tệp đó.

Bây giờ người quản lý của bộ phận mà phần mềm này chủ yếu không thích ý tưởng đó lắm. Anh ấy nghĩ rằng nếu chúng tôi chỉ có một mật khẩu đặt sẵn đơn giản, nó sẽ dễ dàng 'thoát ra' và anh ấy không muốn người dùng thiếu kinh nghiệm truy cập các tính năng bổ sung đó.

Vì vậy, câu hỏi của tôi là, có những phương pháp nào khác để cung cấp loại quyền truy cập này sẽ an toàn hơn một chút? Tôi gần như chỉ bảo trì và quản lý phần mềm này, vì vậy mọi thứ gần như không được tích hợp hoàn toàn hoặc tự động sẽ không giúp ích gì (chẳng hạn như gửi yêu cầu cho 'khóa cấp phép' hoặc một cái gì đó tương tự như vậy).

Lưu ý: Ứng dụng này được viết bằng VB.NET (.NET 4.0) và tôi hiện đang có kế hoạch sử dụng triển khai nhấp một lần khi phiên bản mới hoàn tất.

Nếu bạn có Active Directory, bạn có thể kiểm tra tư cách thành viên trong Nhóm Active Directory:

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

Người quản lý nói đúng về mật khẩu nhận được . Nó không phải là vấn đề nếu, nhưng khi nào.

Vì Active Directory không phải là một tùy chọn cho một số người dùng, bạn có thể tạo tệp văn bản đã ký với danh sách tên đăng nhập windows được phép siêu người dùng truy cập. Điều này giả định rằng mọi người không chia sẻ máy tính hoặc đăng nhập.

Tên người dùng sẽ đi vào một tệp văn bản dễ phân phối sẽ được đặt trong thư mục của ứng dụng. Phần quan trọng là ký tên vào danh sách tên người dùng. Giữ nó rất đơn giản. Một tên người dùng trên mỗi hàng và đặt băm trên dòng cuối cùng. Nhúng một số loại khóa bí mật trong nhị phân chương trình của bạn và băm nó với tên người dùng. Khóa bí mật sẽ ngăn mọi người sửa đổi tệp và sau đó tự tính toán hàm băm (có lẽ là rất xa để bắt đầu).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

Tất nhiên, điều này đòi hỏi ai đó ở đâu đó đóng vai trò là quản trị viên của danh sách người dùng được ủy quyền. Quản trị viên nên có một chương trình (được viết bởi bạn!) Tạo tệp và băm. Nếu không có gì khác, nó chỉ có thể lấy một tệp văn bản của tên người dùng và thêm hàm băm.

Vì lợi ích của việc kỹ lưỡng, ai đó đã bị thu hồi quyền truy cập có thể lấy bản sao của tệp vẫn có tên đăng nhập của họ trong đó. Bất cứ khi nào họ muốn truy cập, họ có thể đặt bản sao của họ vào vị trí. Có lẽ không có gì phải lo lắng, mặc dù.

Vì Active Directory không phải là một tùy chọn, tôi sẽ băm ngày hiện tại. Sử dụng các yếu tố có entropy đầu tiên (ngày trong tháng) và những yếu tố có ít entropy cuối cùng (năm). Nếu cần, hãy thêm một loại muối dành riêng cho tên miền (ID khách hàng, tên công ty, v.v. vì nó được sử dụng bên ngoài công ty của bạn). Điều này sẽ tạo ra một mật khẩu rất khác nhau mỗi ngày mà người dùng cuối thực tế không thể đoán được và nó có thể khác nhau đối với các công ty khác nhau sử dụng phần mềm.

Đây thực chất là một vấn đề về gà và trứng vì phần mềm cần có khả năng xác thực người dùng mà không cần gọi điện về nhà. Vì vậy, tạo một quả trứng với một cơ chế bẻ khóa thực sự tối nghĩa: trong khi bảo mật thông qua che khuất không phải là bảo mật thực sự, đây là cách tốt nhất bạn đã đưa ra các tham số của vấn đề của mình.

Điều này cũng tốt hơn so với việc đặt một tệp văn bản ở đâu đó: không tốt hơn mật khẩu tĩnh bởi vì một khi bí mật được đưa ra, trò chơi kết thúc.

Sử dụng Danh sách điều khiển truy cập .

Cách nhanh chóng và bẩn thỉu để làm điều này là xóa tất cả các quyền khỏi thư mục ứng dụng (bao gồm quyền đọc), sau đó thêm các quyền này cho bất kỳ người dùng nào được phép chạy ứng dụng. Tất nhiên, người dùng có quyền có thể dễ dàng sao chép thư mục ứng dụng vào vị trí công cộng, nhưng điều này khó có thể xảy ra một cách tình cờ, trong khi chia sẻ mật khẩu có thể dễ dàng vô tình xảy ra.

Tất nhiên, điều này giả định rằng các máy tính liên quan được bảo mật (hy vọng với thư mục hoạt động).

Sở thích của tôi là như @Dan đề xuất - sử dụng thư mục hoạt động. Nếu điều này là không thể, thì một trình tạo mật khẩu dựa trên thời gian có thể hữu ích. Trong một tình huống tương tự, (quá khứ rất xa) một công ty của tôi mà tôi đã làm việc đã sử dụng 9999-MMDD. Điều này đã nhận ra sau một vài năm. Nếu bạn ném vào hhmm và trộn nó lên một chút, bạn có thể nhận được một hoặc hai năm trước khi ai đó cho mèo ra khỏi túi.

Bạn luôn có thể viết chương trình tạo mật khẩu bằng chiến lược tương tự nhưng phức tạp hơn. Ném vào tên được sử dụng là một tên máy là tốt. Người quản lý của bạn có thể chạy chương trình đó để lấy mật khẩu hiện tại cho máy đó. Lưu trữ một số thông tin trong tệp để nó không hợp lệ nếu được sao chép sang máy khác hoặc nếu người dùng khác đăng nhập. Sau đó, người quản lý của bạn sẽ giữ an toàn cho chương trình và nếu con mèo thoát ra thì đó là lỗi của anh ta.

Lược đồ này được coi là yếu và không đáng tin cậy từ góc độ cyrpto, nhưng là đủ cho vấn đề bạn gặp phải.