У меня есть сценарий, который беспокоит меня годами. Если вам нужно подключиться к базе данных или другой службе (например, веб-службе) с использованием имени пользователя и пароля, где было бы самым безопасным местом для хранения этой информации, если вы подключаетесь через сборку .NET? Я понимаю, что вам нужно будет зашифровать пароль, но тогда вы столкнетесь с проблемой куриного яйца - отлично - вы можете зашифровать его, но тогда куда вы кладете ключ?
В .NET вы не можете жестко задавать пароль, потому что вы можете декомпилировать .NET-код.
Я посмотрел на использование прав на сборке с изолированным хранилищем, но MS рекомендует не хранить незашифрованные секретные элементы там, потому что priveledged пользователи могут получить доступ, поэтому снова мы перемещаем проблему из точки A в точку B. Так, например, m, a администратор домена, не нуждающийся в информации об информации в базе данных, сможет получить доступ из-за возможности быть администратором на любой рабочей станции в домене.
Вы можете шифровать App.Config и Web.Config, но я считаю, что пользователи могут получить доступ к ключам.
Я думаю, что вы столкнулись с той же проблемой с DPAPI.
Я рассмотрел возможность хранения паролей, зашифрованных в удаленной базе данных и получения их через проверку подлинности ОС, но наш отдел запрещает хранение паролей на серверах баз данных. Я уверен, что застрял и хотел подтверждения.
Вы не хотите хранить пароль в сборке, а изобретать колесо только создает больше проблем (и вводит больше уязвимостей), чем того стоит. Если вы используете платформу MS как для базы данных, так и для веб-сервера, то самый простой способ справиться с этим - использовать доверенное соединение и предоставить права на сервере SQL с идентификатором, используемым вашим приложением.
Во-вторых, я просто позволяет DPAPI выполнять свою работу для шифрования настроек подключения.
Вы можете использовать следующие методы .NET Framework для защиты ваших данных, они используют DPAPI для защиты ваших данных, и вы можете напрямую использовать их в С# или VB.NET, без необходимости возиться с вызовами системной DLL:
namespace System.Security.Cryptography
{
// Summary:
// Provides methods for protecting and unprotecting data. This class cannot
// be inherited.
public sealed class ProtectedData
{
public static byte[] Protect(byte[] userData,
byte[] optionalEntropy, DataProtectionScope scope);
public static byte[] Unprotect(byte[] encryptedData,
byte[] optionalEntropy, DataProtectionScope scope);
}
}
Чтобы использовать его, добавьте ссылку System.Security в свой проект. Я настоятельно рекомендую использовать массив байтов optionalEntropy для добавления SALT в ваши защищенные данные (добавьте некоторые случайные значения в массив байтов, которые уникальны для данных, которые вы намереваетесь защитить).
Для scope вы можете использовать DataProtectionScope.CurrentUser, который будет шифровать данные для защиты с текущими учетными данными пользователя.
В некоторых сценариях полезно использовать DataProtectionScope.LocalMachine. В этом случае защищенные данные связаны с машинным контекстом. С помощью этой настройки любой процесс, выполняемый на компьютере, может снять защиту. Он обычно используется в приложениях, специфичных для сервера, которые выполняются на сервере, где недоверенным пользователям не разрешен доступ.
Используйте метод Protect для шифрования данных, расшифруйте его с помощью Unprotect. Вы можете сохранить возвращаемый массив байтов в соответствии с требованиями вашего приложения (файл, база данных, реестр и т.д.).
Подробнее об этих методах можно найти здесь, в MSDN:
ProtectedData,ProtectДля образцов кода и в случае, если вы заинтересованы в шифровании частей файла .config приложений, проверьте это:
Я рекомендую вам использовать СОЛЬ (т.е. с помощью параметра optionalEntropy) - он защищает от атаки радужных таблиц.
Есть один недостаток решения DPAPI, которое я хотел бы упомянуть: ключ создается на основе ваших учетных данных Windows, а это значит, что у любого, кто имеет доступ к вашим учетным данным Windows, возможно, доступ к защищенным данным. Программа, работающая под вашей учетной записью, также может получить доступ к защищенным данным.
Это хороший вопрос, и я сам искал ответ. Проблема была в том, чтобы защитить пароли db в случае взлома сервера и получить отдельные файлы. Один очень интересный вариант, который я нашел, заключается в том, что разделы web.config могут быть зашифрованы и дешифрованы автоматически "на лету" платформой .NET, которая будет использовать безопасное хранилище Windows, чтобы сохранить и получить ключ шифрования для вас. В моей ситуации это было недоступно, потому что мой хостинг-провайдер не поддерживал его, но вы можете взглянуть на этот вариант. Почему я думаю, что это может работать, так это то, что вы можете самостоятельно управлять безопасностью того, что пользователи могут получить в безопасном хранилище Windows, и значительно ограничить любые возможные нарушения. Хакер, который попадает на сервер, может получить копию ваших конфигурационных файлов, и все ваши сборки, но доступ к ключу дешифрования станет для него еще одним препятствием.
Здесь есть несколько вариантов.