Где вы храните свои строки подключения?

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

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

В мире .NET я в настоящее время храню этот жестко запрограммированный идентификатор/пароль в файле app.exe.config. Рекомендуемый метод — зашифровать строку подключения в файле?

Какие классы я могу использовать для этого шифрования/дешифрования?


frameworks .net connection-string
person abhi    schedule 30.07.2010    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Читать:

Шифрование информации о конфигурации в приложениях ASP.NET 2.0

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

Для шифрования вы должны использовать утилиту aspnet_regiis, что-то вроде этого:

aspnet_regiis.exe -pef "connectionStrings" "C:\Inetpub\wwwroot\MySite"

А для расшифровки — ничего делать не надо, .NET прозрачно для вас с этим справляется.

ОБНОВЛЕНИЕ: эти механизмы для ВСЕХ .NET — они являются частью базовой инфраструктуры .NET. Вы можете использовать эти методы и рецепты для своего консольного приложения или службы Windows. Microsoft предоставляет только инструменты для случая ASP.NET для шифрования разделов web.config, но API и вызовы доступны всем для использования в любом приложении .NET — сделал это сам, в любом консольном приложении, чтобы служба Windows.

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

person marc_s    schedule 30.07.2010
comment
Почему все голосуют за это? ОП даже не работает на ASP.NET! - person Josh Stodola; 30.07.2010
comment
Я думаю, если кто-то отвечает, и его репутация превышает 50 тысяч, он должен быть гением, который всегда прав...? Это не удар по marc_s; Я постоянно вижу, как это происходит здесь, и это наносит ущерб ценности сообщества. Это нужно остановить. - person Josh Stodola; 30.07.2010
comment
Marc_S, я работаю над клиентским приложением. Ничего общего с ASP.NET. Судя по внешнему виду утилиты, она работает с IIS. - person abhi; 30.07.2010
comment
@Matthew, для клиентского приложения? Какие у меня будут параметры? - person abhi; 30.07.2010
comment
@ Мэтью Конечно, я пробовал. Он реализован в каждом веб-приложении, которое у меня есть в производстве. Однако это не имеет никакого отношения к этому вопросу! ОП (@abhi) говорит о приложении Windows. - person Josh Stodola; 30.07.2010
comment
dotnetprofessional.com/blog/ сообщение/2008/03/ - person Matthew Whited; 30.07.2010
comment
Конечно, большая проблема может быть связана с тем, что это могут быть распределенные приложения. Я совершенно уверен, что это использует ключ шифрования машины. Но если вы зашифруете свою конфигурацию с помощью известного ключа для приложения, чтобы его можно было распространять, вы будете менее защищены, потому что люди могут просто использовать ваш ключ для расшифровки. - person Matthew Whited; 30.07.2010
comment
@Josh Stodola, @abhi: эти механизмы работают во ВСЕХ .NET - НЕ только в ASP.NET - поэтому я надеюсь, что мой ответ все еще представляет некоторую ценность для ОП. - person marc_s; 31.07.2010
comment
@ Джош Стодола: учитывая, что мое предложенное решение РАБОТАЕТ для всех приложений .NET, я думаю, что ваш отрицательный голос неуместен ..... - person marc_s; 31.07.2010

arrow_upward
3
arrow_downward

Шифровать строки подключения в файлах .config VS 2005

person Raj    schedule 30.07.2010