Каков наилучший способ сохранить строку подключения в .NET DLL?

Question

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

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

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

Обновить:Спасибо всем, кто ответил.Я постараюсь ответить на некоторые из заданных мне вопросов...Библиотека данных DLL используется как ASP.NET WebForms, так и VB.NET WinForms.Я понимаю, что приложения могут иметь свои собственные конфигурационные файлы, но я ничего не видел о конфигурационных файлах для DLL.К сожалению, я не могу попасть на почту Джона Гэллоуэя на работе, поэтому не могу судить, сработает ли это.С точки зрения разработки, мы не хотим использовать собственные веб-сервисы, но, возможно, будем предоставлять их третьим лицам где-то в следующем году.Я не думаю, что олицетворение сработает, потому что мы не можем аутентифицировать пользователя через брандмауэр.Поскольку пользователь (или бывший пользователь) может быть злоумышленником, мы скрываем это от всех!

Answer 1

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

Обновить:Смотрите сообщение Джона Гэллоуэя вот.

Answer 2

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

Answer 3

Мне неприятно это говорить, но как только вы размещаете что-то на клиентском компьютере, безопасность этих данных исчезает.

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

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

Позвольте мне задать вопрос.От кого вы скрываете строку подключения?Пользователь или злоумышленник?И если пользователь, то почему?

Answer 4

Есть и еще несколько идей.Вы всегда можете использовать олицетворение.Кроме того, вы можете использовать Корпоративную библиотеку (Common Library).

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<enterpriseLibrary.ConfigurationSource selectedSource="Common">
<sources>
  <add name="Common" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
    filePath="Config\Exception.config" />
</sources>

Answer 5

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

Answer 6

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

Возможно, вам нужно переосмыслить, какую ответственность должна нести ваша библиотека DLL.Было бы возможно или имело бы смысл требовать, чтобы строка подключения передавалась пользователем вашей библиотеки?Действительно ли имеет смысл, что ваша библиотека DLL считывает конфигурационный файл?

Answer 7

Если приложение является приложением ASP.NET, то просто зашифруйте раздел строк подключения вашего web.config.

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

Просто несколько мыслей.

Обновленный: @лассевк

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

Безопасность веб-сервиса была неявной.В зависимости от типа развертывания существует множество вариантов...например, сертификаты на стороне клиента.

Answer 8

Несколько вариантов:

1. Храните в web.config и шифруйте
2. Хранить в библиотеке dll и запутывать (dotfuscator)
3. Сохраните один из них в web.config (разумеется, зашифрованный) и сохраните в базе данных (если вам приходится использовать несколько и шифрование / дешифрование становится проблемой)