Отправка пароля в службу Windows

Question

Как лучше всего отправить пароль в службу Windows? Наше приложение требует пароль для запуска. Мне все равно, что службы "нормально" должны работать без взаимодействия с пользователем. Для нас достаточно того, что оператор может запустить приложение и затем выйти из системы.

В Unix-системе я просто вводил бы пароль поверх стандартного ввода, но у службы нет стандартного ввода.

В настоящее время мы используем DPAPI, чтобы просто сохранить пароль с помощью CryptProtectData. Хотя это работает, оно создает другие проблемы, которые начинают становиться хлопотными.

Я предполагаю, что мне потребуется использовать некоторую форму IPC между службой и приложением, которое отправляет пароль, но я не уверен, какой метод подходит, если таковой имеется.

Спасибо

Answer 1

Два основных варианта:

Вы можете прослушать сокет при запуске и подождать, пока не будет введен необходимый пароль (возможно, встроить SSH-сервер, чтобы пароль не мог быть прослушан по сети)

Мой предпочтительный вариант - чтение пароля из файла конфигурации (который может быть защищен до минимального количества читателей) или настроек реестра (опять же, достаточно безопасных, чтобы только ваша служба и администраторы могли читать / изменять его)

Answer 2

Вы можете получить доступ к удаленному диску из службы, работающей под системной учетной записью. Тем не менее, вам необходимо иметь учетные данные и обмениваться информацией для подключения к удаленному компьютеру. Вы можете использовать API wnetaddconnection для получения доступа. Возможно, ваш зашифрованный файл может хранить и эти учетные данные.

Answer 3

Какие именно проблемы были начинают беспокоить? Может быть мы можем просто решить эти ...

В настоящее время приложение запускается как учетная запись локальной системы.

Наше приложение хранит несколько учетных данных в зашифрованном файле и использует DPAPI (в UserMode) для шифрования.

Таким образом, когда приложение установлено, программа установки запускается как учетная запись локальной системы. У нас также есть набор инструментов, которые поставляются вместе с приложением, некоторые из которых нуждаются в доступе к этому зашифрованному файлу и, следовательно, они также должны работать как учетная запись локальной системы.

К тому времени, когда приложение установлено и запущено, мы сильно зависим от этой учетной записи.

У нас проблемы, потому что один из наших пользователей хочет использовать приложение для доступа к общему сетевому диску. У учетной записи локальной системы нет таких привилегий, и мы не можем просто запустить наш сервис от имени другого пользователя, поскольку наша зашифрованная информация защищена учетной записью локальной системы.

Мы постарались избежать процесса настройки учетной записи пользователя только для нашего приложения, поскольку оно установлено во многих различных клиентах и ​​средах, у всех из которых совершенно разные политики безопасности.

Answer 4

DPAPI в UserMode - действительно лучший вариант, и хранение зашифрованных данных в защищенном месте, например ключ реестра с ограниченным ACL.
Какие именно проблемы стали проблематичными? Может быть, мы можем просто решить эти ...

Answer 5

Вы можете использовать взаимную аутентификацию kerberos . Там есть несколько вариантов и примеров.

Но просто интересно. На скомпрометированной машине может присутствовать регистратор ключей. Поэтому ввод пароля никогда не бывает безопасным, если вы хотите поддерживать безопасность в этой среде. Та же самая проблема существует на юникс терминалах.

Answer 6

Спасибо, что ответили, Роуленд.

Вы можете слушать на сокете запустите и дождитесь требуемого пароль должен быть предоставлен (возможно, встроен там SSH-сервер, так что пароль не может быть обнаружен провод)

Я считал, что без проверки сертификата разве это не оставит нас открытыми для человека в середине атаки?

Мой предпочтительный вариант - читать пароль из файла конфигурации (это может быть обеспечено до минимума читаемость) или настройки реестра (опять же, достаточно безопасно, чтобы только ваш сервис и администраторы могу прочитать / изменить)

Мы стараемся максимально тщательно следить за «глубокой защитой», чтобы в случае взлома компьютера он не смог получить доступ к нашему приложению.