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

Question

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

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

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

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

Answer 1

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

Обновление: см. Пост Джона Галлоуэя здесь.

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

<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 8

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

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

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

Обновлено: @ lassevk

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

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