Які можливі альтернативи для надання пароля адміністратора для настільного додатка?

В даний час я керую і переосмислюю частину програмного забезпечення, яке використовується в моїй компанії вже більше десяти років. Одним з елементів цього додатка є свого роду режим адміністрування або користування, який забезпечує такі можливості, як деякий додатковий / внутрішній вхід, а також можливість вимкнути межі введення.

Історично цей режим був увімкнений, помістивши спеціально названий файл у певному місці в системній директорії Windows (обидва вони були жорстко закодовані у програму), при цьому файл отримав назву "something.DLL", хоча він був порожнім ASCII файл, а не dll.

Тому я нещодавно додав код і трохи модальної форми, яка дозволяє користувачеві ввести пароль адміністратора, щоб увімкнути цю функціональність. Це встановлений пароль, а не конкретний для користувача. Коли вводиться правильний пароль, він робить щось таке ж, створюючи «ключ-файл» у кореневому каталозі програм, щоб програма могла запуститися в режимі адміністратора, якщо цей файл присутній.

Зараз менеджеру відділу, для якого це програмне забезпечення в основному, не дуже подобається ця ідея. Він вважає, що якщо у нас є просто простий заздалегідь заданий пароль, він легко "вийде", і він не хоче, щоб недосвідчені користувачі отримували доступ до цих додаткових функцій.

Отже, моє питання полягає в тому, які існують інші методи для надання такого доступу, які були б дещо безпечнішими? Це майже все, що стосується підтримки та управління цим програмним забезпеченням, тому все, що майже не повністю вбудовано або не автоматизовано, не допоможе (наприклад, надсилання запитів на "ліцензійні ключі" чи щось подібне до цього).

Примітки: Ця програма написана у VB.NET (.NET 4.0), і я зараз планую використовувати розгортання за натисканням одного разу, коли буде виконана нова версія.

Якщо у вас є Active Directory, ви можете протестувати на членство в групі 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;
    }

Менеджер має рацію щодо виходу пароля . Справа не в тому, якщо, але коли.

Оскільки Active Directory не є варіантом для деяких користувачів, ви можете створити підписаний текстовий файл із переліком імен для входу в Windows, яким дозволений суперкористувач. Це передбачає, що люди не діляться комп'ютерами та логінами.

Імена користувачів просто переходитимуть у легко розповсюджений текстовий файл, який буде поміщений у папку програми. Важливою частиною є підписання списку імен користувачів. Зберігати це дуже просто. Одне ім’я користувача на рядок, а хеш - останній рядок. Вставте якийсь секретний ключ у бінарний програму і хешуйте його з іменами користувачів. Секретний ключ не дозволить людям змінювати файл, а потім обчислювати хеш (що, мабуть, надумано для початку).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

Це, звичайно, вимагає, щоб хтось десь виступав адміністратором списку авторизованих користувачів. У адміністратора повинна бути програма (написана вами!), Яка генерує файл і хеш. Якщо нічого іншого, він може просто взяти текстовий файл імен користувачів та додати хеш.

В інтересах бути ретельним хтось, кому було відкликано доступ, може схопити копію файлу, який досі має ім’я для входу. Щоразу, коли вони хотіли доступу, вони могли просто поставити свою копію на місце. Напевно, не про що турбуватися.

Оскільки Active Directory не є можливим, я б хеш-код поточної дати. Використовуйте елементи з найбільшою ентропією першого (день місяця) та ті, у кого найменша ентропія минулого (рік). Якщо потрібно, додайте сіль для домену (ідентифікатор клієнта, назва компанії тощо, оскільки вона використовується за межами вашої компанії). Це повинно створювати дуже різний пароль кожного дня, що практично неможливо здогадатися кінцевим користувачам, а він може бути різним для різних компаній, які використовують програмне забезпечення.

Це, по суті, проблема з куркою та яйцями, оскільки програмне забезпечення повинне мати змогу аутентифікувати користувача, не телефонуючи додому. Тож зробіть яйце із дійсно незрозумілим механізмом розтріскування: хоча безпека через неясність не є реальною безпекою, це найкраще, що ви задали параметри вашої проблеми.

Це також краще, ніж десь розмістити текстовий файл: це не краще, ніж статичний пароль, тому що, як тільки секрет вийде, гра закінчиться.

Використовуйте списки контролю доступу .

Швидкий і брудний спосіб зробити це - видалити всі дозволи з каталогу програм (включаючи дозвіл на читання), а потім додати ці дозволи для будь-яких користувачів, яким дозволено запускати програму. Звичайно, користувач з дозволом може так само легко скопіювати каталог додатків у загальнодоступне місце, але це навряд чи трапиться випадково, тоді як обмін паролем може легко трапитися випадково.

Це, звичайно, передбачає, що задіяні комп'ютери захищені (сподіваємось, з активною каталогом).

Мої переваги такі, як запропонував @Dan - використовувати активний каталог. Якщо це неможливо, то може бути корисним генератор паролів на основі часу. У подібній ситуації (дуже далеке минуле) одна моя компанія, в якій я працював, використовувала 9999-MMDD. Це все вийшло через пару років. Якщо ви кинули хммм і трохи змішали його, ви можете отримати рік-два, перш ніж хтось випустить кота з мішка.

Ви завжди можете написати програму, яка генерує пароль, використовуючи подібну, але більш складну стратегію. Впишіть у використане ім’я також ім'я машини. Ви можете запустити цю програму, щоб отримати поточний пароль саме для цієї машини. Зберігайте деяку інформацію у файлі, щоб вона не була дійсною, якщо її скопійовано на іншу машину або якщо інший користувач увійшов у систему. Її слід вирішувати менеджеру, щоб захистити програму, і якщо кішка вийде, вона винна.

Ця схема вважається слабкою та ненадійною з кірптової точки зору, але є адекватною для вашої проблеми.