Шифрование разделов и / или настроек в файле App.config, который будет распространяться - PullRequest
8 голосов
/ 05 февраля 2010

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

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

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

Будем весьма благодарны за любые ответы или ссылки на статьи о том, как это сделать. Спасибо

Ответы [ 3 ]

8 голосов
/ 05 февраля 2010

Если вы пытаетесь зашифровать строку подключения в вашем App.Config / Web.Config, вы можете сделать это, используя класс конфигурации:

Configuration config = ConfigurationManager.   OpenExeConfiguration(ConfigurationUserLevel.None);
ConfigurationSection section =    config.GetSection("connectionStrings");
if (section != null)
{
    if (!section.IsReadOnly())
    {
        section.SectionInformation.ProtectSection             ("RsaProtectedConfigurationProvider");
        section.SectionInformation.ForceSave = true;
        config.Save(ConfigurationSaveMode.Full);
    }
}

Существует два метода: RsaProtectedConfigurationProvider и DPAPIProtectedConfigurationProvider

Смотрите это -> http://www.codeproject.com/KB/cs/Configuration_File.aspx и http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx.

1 голос
/ 05 февраля 2010

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

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

Ответ лежит в анти-отладке: http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx

Более продвинутые окна Анти-отладка:

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/

http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/

http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/

http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/

0 голосов
/ 05 февраля 2010

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

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

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

Надеюсь, это поможет, С наилучшими пожеланиями, Том.

...