Где хранить пароли БД при использовании приложений Windows .NET или ASP.NET - PullRequest
12 голосов
/ 08 марта 2012

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

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

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

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

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

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

Ответы [ 4 ]

9 голосов
/ 08 марта 2012

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

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

3 голосов
/ 11 марта 2013

Вы можете использовать следующие методы .NET Framework для защиты ваших данных, они используют DPAPI для внутренней защиты ваших данных, и вы можете напрямую использовать их в C # или 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, может иметь доступ к защищенным данным. Программа, работающая под вашей учетной записью, также может получить доступ к защищенным данным.

1 голос
/ 09 марта 2012

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

0 голосов
/ 08 марта 2012

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

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