Безопасность строки подключения в настольном приложении .net - PullRequest
5 голосов
/ 27 января 2010

Я разрабатываю настольное приложение .net winforms, предназначенное для запуска в нескольких филиалах банка в качестве приложения резервного копирования, когда основное (веб-приложение) недоступно из-за проблем с соединением с центральным узлом банка. Сами ветви не учитываются ни с какими корпоративными службами, кроме базы данных SQL-Server. По этой причине приложение должно иметь возможность подключаться напрямую к SQL-серверу. Моя проблема возникает, когда я должен предоставить приложению пароль для подключения к базе данных:

1) Хранение пароля в виде открытого текста в файле app.config или аналогичном не является вариантом (клиент требует, чтобы пароль был зашифрован)

2) Хранение пароля, зашифрованного в файле конфигурации, приводит к необходимости наличия локального ключа шифрования. Ключ шифрования может быть просто жестко закодирован в коде приложения, но его можно легко прочитать с помощью .net-декомпилятора или аналогичного.

3) Использование специального алгоритма для шифрования / дешифрования также не будет работать по тем же причинам, что и 2).

4) Встроенная защита не поддерживается банком

Кроме того, клиенты требуют, чтобы они могли сменить пароль в одном месте (в пределах филиала) без необходимости переходить с одного компьютера на другой, обновляя файлы конфигурации (что исключает возможность использования ключа компьютера для зашифруйте пароль в конфигурационных файлах отдельной машины, как это делает asp.net)

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

Ответы [ 4 ]

1 голос
/ 27 января 2010

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

Я могу подумать о двух способах, которые могли бы сработать, но, боюсь, они не совсем то, что вы ищете.

  1. Снять требование наличия Пользователь отправляет пароль на сервер используя какой-то локальный прокси (например, используя окна WCF сервис) принять вашу форму запросы, а затем отправьте их на свой имя для сервера БД. если ты установить сервис, используя аккаунт отличается от учетной записи пользователя, тогда вы можете защитить пароль любое из средств, упомянутых в другом ответы. Они ключ здесь, чтобы сделать уверен, что пользователь приложения не иметь доступ к ресурсам, которые учетная запись службы должна быть расшифрована пароль.
  2. Не храните пароль в веб-конфигурации. Назначьте каждому пользователю разные учетную запись и пароль на уровне базы данных и попросите их ввести их при входе в систему.
1 голос
/ 27 января 2010

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

0 голосов
/ 27 января 2010

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

0 голосов
/ 27 января 2010

Вы можете

  • Чтобы использовать DPAPI для безопасного хранения ключа шифрования / дешифрования: Как: использовать DPAPI для шифрования и дешифрования данных
  • Для установки SQL Server Compact Edition (или другой небольшой базы данных) на ваши рабочие станции и синхронизировать данные при повторном подключении вашего веб-приложения.
  • Чтобы обратиться за помощью в это учреждение, как могли бы другие людирешил эту проблему и мог бы вам помочь.
...