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

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

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

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

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


.net sql-server connection-string
person proudgeekdad    schedule 08.08.2008    source источник

Ответы (8)


arrow_upward
10
arrow_downward

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

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

person Adam V    schedule 08.08.2008
comment
Обновление больше ни на что не указывает, если вы сможете найти информацию, на которую вы ссылались, и поместить ее в этот ответ, тогда она будет сохраняться навсегда (или как только Stack Overflow будет поглощен солнцем) - person Jason Sperske; 15.12.2015
comment
@JasonSperske - обновил ссылку. Подведу итоги вкратце. - person Adam V; 15.12.2015

arrow_upward
3
arrow_downward

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

person Webjedi    schedule 25.08.2008
comment
Я всегда стараюсь максимально ограничить вход в систему SQL для веб-приложений, над которыми я работал. - person Matt Blaine; 21.09.2008

arrow_upward
1
arrow_downward

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

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

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

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

person Lasse V. Karlsen    schedule 08.08.2008

arrow_upward
0
arrow_downward

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

person Brian Childress    schedule 08.08.2008

arrow_upward
0
arrow_downward

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

person EndangeredMassa    schedule 08.08.2008

arrow_upward
0
arrow_downward

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

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

person Brad Barker    schedule 08.08.2008

arrow_upward
0
arrow_downward

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

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

Просто мысли.

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

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

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

person Kev    schedule 08.08.2008

arrow_upward
0
arrow_downward

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

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