2012-02-25 2 views
2

я создал настольное приложение в C#/WPF, который подключается к экземпляру SQL Server 2008 с помощью постоянной строки соединения, указанной в коде следующим образом (для целей тестирования):Строки подключения для настольного приложения

private string GetConnectionString() 
{ 
    //test 
    return "Data Source=[server IP]; Initial Catalog=[database name]; User ID=[user ID]; Password=[smart password];"; 
} 

Приложение будет использоваться различными пользователями и будет развернуто через ClickOnce, ZIP-архив или пользовательский установщик. Он также имеет разделенные пользовательские функции входа в систему, запрашивая имя пользователя и пароль для доступа к приложениям.

Какова наилучшая практика для хранения сведений о строках подключения для моего настольного приложения (IP, база данных, пользователь SQL Server, пароль)? Если строка соединения изменяется ночью, что является лучшим способом ее обновления, не заставляя пользователей обновляться до последней версии моего приложения? Пользователи не должны видеть/перехватывать/декомпилировать строку подключения, поэтому я предполагаю, что я должен использовать какое-то шифрование. У вас есть какие-либо предложения для моего запроса?

+1

Если соединение изменчиво, тогда будет указано где-то центральное (я предполагаю, что это находится в одной локальной сети компании), например 'NETLOGON'. Что касается предотвращения чтения пользователями - тратите больше времени на работу с функциями, ценными для пользователей, а не на тщетные усилия, такие как это. Если программа, работающая под учетной записью пользователя, может получить доступ к этой информации, тогда пользователь сможет. –

+0

Должны ли пользователи проходить аутентификацию для использования приложения? Я обдумываю наличие «незащищенного» подключения к базе данных, которое поддерживает аутентификацию пользователя и возвращает информацию о соединении, необходимую для выполнения дополнительных функций. Функция проверки подлинности может иметь встроенную задержку времени, если вы обеспокоены тем, что злоумышленник обнаружил соединение и попробовал пары имени пользователя и пароля, а также обычный счетчик сбоев и блокировку учетной записи. – HABO

+0

@Damien_The_Unbeliever: Я рассматриваю этот вопрос как проблему безопасности, о которой я должен заботиться, оценивая все возможности. Я ищу лучшую практику, а не идеальный 100% -ный безопасный способ сделать это :) Вы правы, работа над полезными функциями является приоритетом, но давайте просто не будем игнорировать мелкие детали. –

ответ

5

Даже если вы скомпилируете свои строки подключения в приложение, их по-прежнему можно просмотреть с помощью инструмента Ildasm.exe (MSIL Disassembler), потому что строки являются частью метаданных сборки.

Возможно, this question может вам помочь.

3

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

+0

Это правда. Я даже использовал рефлектор .NET для экспорта сборки в csproj и перестроил DLL с некоторыми изменениями кода, чтобы я мог выработать пароль. Также я хотел, чтобы потом изменить пароль в базе данных и на клиенте, чтобы я не использовал пароль по умолчанию, используемый поставщиком. –

1

Вам необходимо добавить в приложение файл «Настройки приложения». Просто щелкните правой кнопкой мыши по вашему решению -> add -> найдите что-то похожее на «конфигурацию приложения». Для этого вам понадобится внешний файл конфигурации для хранения строки подключения. Вы даже можете использовать простой файл. Если вы беспокоитесь о поиске файла, вы всегда можете зашифровать строку и расшифровать ее в своем приложении.

2

Если клиент подключается к базе данных, соединение может быть взломан.

Это выборка данных соединений в App.Config

<appSettings> 
     <add key="dbServer" value="svr"/> 
     <add key="dbDataBase" value="db1"/> 
     <add key="dbUser" value="sharedUser"/> 
     <add key="dbPassword" value="easyPassword"/> 
    </appSettings> 

Нужна ссылка на System.Configuration

 string SvrName = ConfigurationManager.AppSettings["dbServer"]; 
     string DBName = ConfigurationManager.AppSettings["dbDataBase"]; 
     string DBUser = ConfigurationManager.AppSettings["dbUser"]; 
     string DBPassword = ConfigurationManager.AppSettings["dbPassword"]; 

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

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

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

1

Мое мнение, что самым безопасным решением является локальная точка входа в DNS для текущей машины SQL, а аутентификация - Проверка подлинности Windows.

Например: имя узла SQLMACHINE, указанное на сервере 192.168.1.3, на DNS-сервере.

Таким образом, если имя/IP машины SQL изменяется, необходимо обновить только DNS-сервер (и, возможно, локальные DNS-кэши будут недействительными).

Проверка подлинности Windows означает, что на локальном компьютере не будет сохранен пароль, чтобы вы могли безопасно хранить строку подключения в файле .config без каких-либо проблем.

Мои 2 (евро) цента.

+0

Но это не защищает БД. Если у пользователя есть доступ к БД через их проверку подлинности Windows, они могут выбирать, вставлять, обновлять и удалять записи с использованием TSQL. Я согласен, что пользователь должен пройти аутентификацию и пароль не хранится на локальном компьютере. DB может быть взломан только аутентифицированными пользователями. – Paparazzi

+0

Я не сказал, что это идеальное решение ... у него есть недостатки :) –

Смежные вопросы