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

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

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

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

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

8.08.2008 16:32:30
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

10
15.12.2015 14:38:20
Обновление больше ни на что не указывает, если вы сможете найти информацию, на которую вы ссылались, и вставить ее в этот ответ, то она будет существовать вечно (или как только переполнение стека поглотит солнце)
Jason Sperske 14.12.2015 21:08:36
@JasonSperske - я обновил ссылку. Я подведу итог в ближайшее время.
Adam V 15.12.2015 14:38:37

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

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

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

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

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

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

0
23.05.2017 11:46:28

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

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

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

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

1
8.08.2008 17:12:58

Есть и другая идея. Вы всегда можете использовать олицетворение. Кроме того, вы можете использовать Enterprise Library (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>

0
8.08.2008 17:28:06

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

0
8.08.2008 17:30:27

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

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

0
8.08.2008 17:40:28

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

3
25.08.2008 05:12:51
Я всегда стараюсь ограничить вход в SQL для веб-приложений, над которыми я работал, как можно больше способов.
Matt Blaine 21.09.2008 07:35:30

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

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