Как шифровать и дешифровать конфиденциальную информацию на C# без введенного пользователем пароля

Question

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

Вот сценарий. У меня есть внутреннее приложение на внутреннем сервере: не то, что будет когда-либо выходить на сайт клиента. Это приложение имеет базу данных пар имени пользователя и пароля, которые используются для связи с защищенными веб-службами. Мне не нужно скрывать эти пароли от коллег, но я хочу защитить их в случае нападения на сервер и кражи данных.

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

Итак: поиск вокруг есть различные решения, которые используют фиксированную «пропущенную фразу» для защиты строки. Вот один пример: https://stackoverflow.com/a/10177020/271907 и вот еще https://stackoverflow.com/a/10366194/188474.

Однако, как я понимаю, ни одно из них не предлагает полезного решения в моем случае. Эта фраза «передать» должна храниться где-то для моего приложения, чтобы выполнить его работу. Если я буду жестко программировать его в приложение, он может быть изменен в обратном порядке. Если я зашифрую его и поместим в отдельный файл, его можно украсть и обработать, используя радужный стол.

Я изучил использование reg_iis для шифрования ключа согласно Encrypting Web Config using ASPNET_REGIIS, но, честно говоря, это просто оставило меня еще более запутанным. Я даже не уверен, могут ли эти зашифрованные файлы конфигурации быть перенесены между машинами или мне придется перешифровывать между dev и test и live. Я не знаю, насколько они безопасны: AFAIK должен быть ключом где-то, и если есть ключ, он может быть сломан.

Чтобы еще больше мутить воды, я нашел этот ответ, который не использует ключ: https://stackoverflow.com/a/10176980/271907. Однако автор признает, что он устарел, и я не знаю, насколько безопасен результат.

Есть ли какой-либо разумный подход к решению этой проблемы, который не оставляет места в безопасности где-то?

Answer 1

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

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

Даже если ваша безопасность приложения устойчива к камню; ваши пароли по-прежнему остаются текстовыми в вашей БД, и если это скомпрометировано, тогда вас порадуют многие ваши пользователи.

Это говорит о том, что это система с низким уровнем риска только для внутреннего использования. Ваш лучший способ действий может состоять в том, чтобы ваши боссы знали относительный риск и стоимость надлежащей безопасности и позволяли им делать явный деловой звонок (и нести любую будущую вину).

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

Золотое правило: если вы храните пароли вы должны хэш их таким образом, вы не можете обратить

Единственный вариант для вас, чтобы не проверять подлинность вообще - использовать NTLM или AD или OAuth, чтобы получить другую услугу для аутентификации пользователя и просто доверять этому источнику.

---

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

Это может быть проблемой, если все ваши данные о соединении хранятся в web.config или appsettings.json, поскольку компрометация этих файлов может привести к возникновению вашего SQL-сервера или других паролей служб.

Здесь вы можете использовать ASPNET_REGIIS - он позволяет вам добавить секретную конфигурацию, к которой IIS может получить доступ, но это не поддерживается в виде обычного текста с веб-файлами.

В ядре .NET есть Microsoft.Extensions.SecretManager.Tools, которые делают то же самое.

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

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

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