Где хранить пароли db при использовании приложений Windows.NET или ASP.NET

У меня есть сценарий, который беспокоит меня годами. Если вам нужно подключиться к базе данных или другой службе (например, веб-службе) с использованием имени пользователя и пароля, где было бы самым безопасным местом для хранения этой информации, если вы подключаетесь через сборку .NET? Я понимаю, что вам нужно будет зашифровать пароль, но тогда вы столкнетесь с проблемой куриного яйца - отлично - вы можете зашифровать его, но тогда куда вы кладете ключ?

В .NET вы не можете жестко задавать пароль, потому что вы можете декомпилировать .NET-код.

Я посмотрел на использование прав на сборке с изолированным хранилищем, но MS рекомендует не хранить незашифрованные секретные элементы там, потому что priveledged пользователи могут получить доступ, поэтому снова мы перемещаем проблему из точки A в точку B. Так, например, m, a администратор домена, не нуждающийся в информации об информации в базе данных, сможет получить доступ из-за возможности быть администратором на любой рабочей станции в домене.

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

Я думаю, что вы столкнулись с той же проблемой с DPAPI.

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

ОТВЕТЫ

Ответ 1

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

Во-вторых, я просто позволяет DPAPI выполнять свою работу для шифрования настроек подключения.

Ответ 2

Вы можете использовать следующие методы .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:

Для образцов кода и в случае, если вы заинтересованы в шифровании частей файла .config приложений, проверьте это:

Я рекомендую вам использовать СОЛЬ (т.е. с помощью параметра optionalEntropy) - он защищает от атаки радужных таблиц.

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

Ответ 3

Это хороший вопрос, и я сам искал ответ. Проблема была в том, чтобы защитить пароли db в случае взлома сервера и получить отдельные файлы. Один очень интересный вариант, который я нашел, заключается в том, что разделы web.config могут быть зашифрованы и дешифрованы автоматически "на лету" платформой .NET, которая будет использовать безопасное хранилище Windows, чтобы сохранить и получить ключ шифрования для вас. В моей ситуации это было недоступно, потому что мой хостинг-провайдер не поддерживал его, но вы можете взглянуть на этот вариант. Почему я думаю, что это может работать, так это то, что вы можете самостоятельно управлять безопасностью того, что пользователи могут получить в безопасном хранилище Windows, и значительно ограничить любые возможные нарушения. Хакер, который попадает на сервер, может получить копию ваших конфигурационных файлов, и все ваши сборки, но доступ к ключу дешифрования станет для него еще одним препятствием.

Ответ 4

Здесь есть несколько вариантов.

  • Храните их в файле конфигурации, зашифрованном
  • Храните их во внешнем файле, который зашифрован сгенерированным семенем. Обфускайте код, в котором хранится это базовое семя, или храните его в dll С++ (с возможностью декомпиляции).