Шифрование разделов и - или настройки в файле App.config, который будет перераспределен
Я создаю обычное приложение Windows, которое будет распределено нескольким пользователям на моем отделе. Я должен буду включать некоторые пароли возможности соединения в файл App.config, и я, очевидно, не хочу, чтобы конечные пользователи просто разожгли блокнот и посмотрели на пароли.
Несколько статей указывают о том, как шифровать/дешифровать разделы конфигурации, но кажется, что необходимо совместно использовать/поставить некоторые ключи с развертываемым решением.
Существует ли более простой путь только к шифру некоторые настройки так, чтобы они не были читаемы пользователем, но которые не требуют дополнительных шагов или файлов при перераспределении программы? Большой плюс был бы то, что доступ к параметрам конфигурации все еще прозрачен в коде.NET. Я мог всегда просто создавать пользовательский метод солить/зашифровывать строку, и в моем пользовательском коде дешифруют его, но я задаюсь вопросом, существует ли что-то более простое.
Любые ответы или ссылки на статьи о том, как сделать это, значительно ценятся.Спасибо
3 ответа
Если вы пытаясь зашифровать строку подключения в вашем App.Config / Web.Config, вы можете сделать это с помощью класса Configuration:
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 .
В любом случае шифрование и дешифрование файла конфигурации приложения бессмысленно, так как расширение. EXE можно проверить с помощью Reflector !
Конечно, вы можете запутать код, но это превратит отладку в кошмар в производственной среде, где закралась странная неизвестная / неоткрытая ошибка, поскольку вы не сможете сказать, что / где / почему / как отслеживать странную ошибку это будет отображаться только в выпуске, поскольку трассировка стека и сообщения об ошибках также будут запутаны ...
Это то, о чем нужно помнить, и потенциальная ловушка ... пользователь может не быть технически подкованным, но уверен, что они могут теоретически, попросите друга / родственника / партнера взломать / сломать его без вашего ведома .. Этот ответ не предназначен для того, чтобы вас оттолкнуть, и надеюсь, вы не обидитесь на мой ответ ...
Надеюсь, это поможет , С уважением, Том.
Короче говоря, криптография - это не волшебная палочка, которая может волшебным образом исправить небезопасную программу.
Злоумышленник будет пытаться получить пароли из памяти с помощью отладчика во время работы приложения. Пароли также будут существовать в бинарном виде, и их можно легко получить. Использование любого шифрования можно обойти, так как пароль в момент использования должен быть открытым текстом. В любой момент времени, когда используется память, это также можно наблюдать с помощью отладчика.
Ответ заключается в борьбе с отладкой: 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/