Ответ 1
Я не уверен, но я считаю, что вы можете поместить его в файл конфигурации и зашифровать конфигурационный файл.
Обновление: см. сообщение Jon Galloway здесь.
Каков наилучший способ хранения строки подключения в .NET DLL?
В приложении, которое сейчас работает моя команда, есть DLL, которая используется для доступа к базе данных. Приложение не может использовать доверенное соединение, потому что база данных находится за брандмауэром, а сервер домена - нет. Таким образом, кажется, что в строке соединения должно быть имя пользователя и пароль. В настоящее время в DLL есть строка с подключением к базе данных, но я не хочу этого делать, когда мы запускаем, когда сборка может быть разобрана, а имя пользователя и пароль будут прямо там в открытом доступе.
Одним из требований является то, что пароль нужно менять раз в несколько месяцев, поэтому нам нужно будет перевернуть это для нашей внутренней пользовательской базы.
Есть ли способ хранить пароль, зашифрованный таким образом, что мы можем легко распространять его на всю базу пользователей, не сохраняя его в сборке?
ОБНОВЛЕНИЕ: Спасибо всем, кто ответил. Я попытаюсь ответить на некоторые вопросы обратно... DLL данных используется как ASP.NET WebForms, так и VB.NET WinForms. Я понимаю, что приложения могут иметь свои собственные файлы конфигурации, но я ничего не видел в файлах конфигурации для DLL. К сожалению, я не могу добраться до должности Джона Галлоуэя на работе, поэтому я не могу судить, будет ли это работать. С точки зрения разработки, мы не хотим использовать веб-сервисы внутри, но можем предоставить их третьим сторонам в следующем году. Я не думаю, что олицетворение будет работать, потому что мы не можем аутентифицировать пользователя через брандмауэр. Поскольку пользователь (или бывший пользователь) может быть злоумышленником, мы сохраняем его от всех!
Ответы
Ответ 2
Предположим, что плохие парни будут получать учетные данные из вашего файла конфигурации. Это означает, что они смогут войти в вашу базу данных и сделать все, на что способен этот пользователь. Поэтому просто убедитесь, что пользователь не может сделать ничего плохого, как напрямую обращаться к таблицам. Сделайте этот пользователь только способным выполнять определенные хранимые процедуры, и вы будете в лучшей форме. Это одно место, которое пробуждает блеск.
Ответ 3
Мне не нравится это говорить, но как только вы помещаете что-то на клиентскую машину, безопасность этих данных выходит из окна.
Если ваша программа расшифрует эту строку, вам нужно предположить, что злоумышленник может сделать то же самое. Присоединение отладчика к вашей программе будет одним из способов.
Сохранение строки подключения на сервере и получение ее через веб-соединение звучат хорошо, пока вы не поймете, что вам нужна безопасность на этом веб-соединении, в противном случае злоумышленник мог бы просто выдать себя за вашу программу и поговорить с ней соединение.
Позвольте задать вопрос. С кем вы скрываете строку подключения? Пользователь или злоумышленник? И если пользователь, почему?
Ответ 4
Если приложение является приложением ASP.NET, просто зашифруйте строку строк подключения web.config.
Если приложение является клиентским приложением, запущенным на нескольких компьютерах, вместо того, чтобы хранить локальную строку подключения, рассмотрите возможность использования веб-службы или какого-либо другого безопасного механизма для ее централизованного хранения. Это облегчило бы обновление обновлений в будущем, и вы не будете локально хранить строку подключения.
Только некоторые мысли.
Обновлено: @lassevk
"Сохранение строки подключения на сервере и получение ее через веб-соединение звучат хорошо, пока вы не поймете, что вам нужна безопасность в этом веб-соединении, иначе злоумышленник мог бы просто выдать себя за вашу программу и поговорить с ней веб-соединение".
Безопасность в веб-службе неявно. В зависимости от типа развертывания существует множество опций... например, сертификаты на стороне клиента.
Ответ 5
Есть и другая идея. Вы всегда можете использовать олицетворение. Кроме того, вы можете использовать корпоративную библиотеку (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>
Ответ 6
.NET поддерживает шифрование при значениях конфигурации, подобных этому. Вы можете оставить его в конфигурационном файле, но зашифрованном.
Ответ 7
Вы хотите, чтобы иметь возможность распространять DLL со всей информацией о настройке, находящейся в настраиваемом месте, но факт в том, что у вас не может быть одного из удобных файлов конфигурации .NET для DLL, если вы ничего не сделаете обычай.
Возможно, вам нужно переосмыслить, какую ответственность должна иметь ваша DLL. Было бы возможно или иметь смысл требовать, чтобы строка соединения была передана пользователем вашей библиотеки? Действительно ли имеет смысл, что ваша DLL читает файл конфигурации?
Ответ 8
Несколько параметров:
- Хранить в файле web.config и шифровать
- Сохранение в dll и обфускация (dotfuscator)
- Храните один файл в web.config(зашифрованный, конечно), и оставайтесь в базе данных (если вам нужно использовать несколько, а шифрование/дешифрование становится болью)