Быть может подобный вопрос уже появлялся в форуме, но я так и не смог его найти.
В общем, есть в app.config секция connectionStrings. Там у меня есть соответствующая
информация о строке соединения с сервером СУБД.
Встал вопрос о шифровании всего этого дела. В MSDN сказано, что можно спокойно защищать
секции в app.config при помощи крипто-провайдера.
Но есть небольшой нюанс. Они показали, как это делается для ASP.NET и соответственно для
web.config. Защищается информация с помощью утилиты aspnet_regiis.exe с ключом pe.
Все вроде бы и хорошо, но для app.config я не смог разобраться как пользоваться этой утилитой.
Дело в том, что следующим параметром после ключа и имени секции (в общем случае) является
путь к (!!!) корневому каталогу сайта. А о каком сайте можно говорить, если я создаю
desktop-приложение?! Пытался подставить каталог приложения, но естественно получил Failed.
В итоге я не знаю, как зашифровать подобным образом app.config.
Пытался найти информация на Codeproject, но и там нет.
Может кто-нибудь ранее встречался с подобной задачей и сможет подсказать путь ее решения.
Здравствуйте, nomshar, Вы писали:
N>В общем, есть в app.config секция connectionStrings. Там у меня есть соответствующая N>информация о строке соединения с сервером СУБД. N>Встал вопрос о шифровании всего этого дела.
Посмотри Enterprise Library в сторону Configuration Application Block
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Infected Mushroom — Sailing in the Sea of Mushroom
Здравствуйте, nomshar, Вы писали:
N>Быть может подобный вопрос уже появлялся в форуме, но я так и не смог его найти. N>В общем, есть в app.config секция connectionStrings. Там у меня есть соответствующая
Если подключение к MS SQL Server, то лучше использовать роль приложения. Тогда можно ничего не шифровать, т.к имя и пароль "зашиты" в саму программу. Это к тому же предотвратит доступ к базе с помощью сторонних средств для модификации данных или структуры
Re: Защита секций в app.config.
От:
Аноним
Дата:
26.10.05 14:31
Оценка:
Можно, но не в моем случае. Ситуация такая, что приходится подстраиваться под существующую систему. Плюс.
Различных приложений довольно-таки много. Так что connectionString c UserID и Pwd.
Один способ я уже нашел — шифрование всего app.config. То есть пишется некий tool, который будет шифровать файл. Потом соответственно у себя в программе я это дело дешифрую. Но есть минус и даже не один.
Первый — это то, что мне придется самому осуществлять дешифровку, когда как при, например, использовать aspnet_regiis данные автоматически дешифруются при их запросе. Так по-крайней мере сказано в MSDN.
Следующий минус. Предлопожим, у меня не app.config, а mashine.config. Тогда во все приложения, исполняющиеся на машине, мне придется вставить код дешифровки. Что тоже не радует.
В общем, по-прежнему в поисках оптимального решения.
P.S. Никак не могу понять, почему Microsoft не дошли до простейшего решения: напротив каждой секции в Project->Settings поставить checkbox: шифровать, не шифровать.
Но это уже так, лирика.
Может стоит сначала понять: а нужно ли вообще шифровать? И какой алгоритм выбрать? Например, если это приложение находится на машине у конечного пользователя, то, быть может, имеет смысл просто сделать XOR с фиксированой маской, и не заморачиваться с более сложными алгоритмами шифрования, ведь получить данные соединения можно элементрано установив сниффер. Или, например, приложение находится на сервере, доступ к которому имеет только один человек, быть может тоже не стоит тратить свои силы на шифрование данных: даже если зашифровать данные наиболее стойким ассиметричным алгоритмом, то администратор, например, может вытащить секретный ключ прямо из assembly и расшифровать данные...
Другое дело, если приложение находится у множества конечных пользователей, но не соединяется напрямую с БД, а передает защифрованые данные серверному приложению, которое данные расшифровывает и выполняет соединение, тогда, скорее всего, действительно понадобится данные шифровать криптостойкими алгоритмами. И то надо смотреть на все это дело с точки зрения экономической целесообразности: какие затраты уйдут на разработку/поддержку и какие убытки/затраты могут быть если вдруг злоумышленник узнает логин/пароль и воспользуется данной информацией...
По поводу шифрации конфига: есть стандарт XML Encryption, который позволяет шифровать отдельные ноды xml-документа, поэтому если одним конфигом пользуются несколько различных приложений, не обязательно в каждое из них встраивать декриптер, достаточно будет модифицировать только те, которым нужно знать расшифрованое значение этой ноды. XML Encryption вроде как поддерживается в .Net 2.0, но насколько корректно — не знаю. Есть и компоненты сторонних производителей, которые поддерживают сей стандарт, пару лет назад для подписи/шифрации XML-документов сам использовал такой ActiveX — компонент, который предоставлял все необходимые security-функции.
Чувствую, что видимо придется воспользоваться продуктами третьей стороны.
По поводу приложения. Вообще это сугубо внутренний софт, использующий двухзвенную систему — прямое обращение к базе.
На самом деле не хотелось бы что-то выдумывать. Нужен некий общий, стандартный механизм защиты конфигурационного файла для .NET 2.0.
Думал, что Microsoft дает такую возможность и как-то это дело автоматизирует, как это реализовано (правда, не очень хорошо) для web.config. Но пока ничего нет. Пока ни MSDN, ни CodeProject, ни CodeGuru ничего по этому поводу не говорят. Хотя на CodeGuru есть небольшая статья по этому поводу, но указанный там метод непрактичен (предлагают в каждом своем проекте классе создавать метод для шифрования строк и использовать Object Test Bench).
Так что, либо пока придется отложить эту тему до лучших времен, либо искать решения от других компаний-разработчиков, либо писать что-то свое.
Благодарю всех за исчерпывающие ответы.
Здравствуйте, nomshar, Вы писали:
N>Чувствую, что видимо придется воспользоваться продуктами третьей стороны. N>По поводу приложения. Вообще это сугубо внутренний софт, использующий двухзвенную систему — прямое обращение к базе. N>На самом деле не хотелось бы что-то выдумывать. Нужен некий общий, стандартный механизм защиты конфигурационного файла для .NET 2.0. N>Думал, что Microsoft дает такую возможность и как-то это дело автоматизирует, как это реализовано (правда, не очень хорошо) для web.config. Но пока ничего нет. Пока ни MSDN, ни CodeProject, ни CodeGuru ничего по этому поводу не говорят. Хотя на CodeGuru есть небольшая статья по этому поводу, но указанный там метод непрактичен (предлагают в каждом своем проекте классе создавать метод для шифрования строк и использовать Object Test Bench). N>Так что, либо пока придется отложить эту тему до лучших времен, либо искать решения от других компаний-разработчиков, либо писать что-то свое. N>Благодарю всех за исчерпывающие ответы.
Еще раз настоятельно советую посмотреть на Enterprise Library. В документации (устанавливается вместе с самой библиотекой) необходимо отыскать "Encrypting Configuration Data" для "Configuration Application Block", где написано все, что необходимо.
Protecting Configuration Data in a Configuration Section
Each configuration section, which generally corresponds to one of the application blocks, can be encrypted to protect sensitive data and keys. All sections are encrypted with the same key pair algorithm. You select this algorithm when you determine the encryption settings for the Configuration Application Block.
А общаться с таким зашифрованным конфигурационным файлом очень легко и прозрачно:
// Чтение
EditorFontData configData = (EditorFontData) ConfigurationManager.GetConfiguration("EditorSettings");
string FontName = configData.Name;
// Запись
EditorFontData configData = new EditorFontData();
configData.Name = fontDialog.Font.Name;
configData.Size = fontDialog.Font.Size;
configData.Style = Convert.ToInt32(fontDialog.Font.Style);
// Write the new configuration data to the XML file
ConfigurationManager.WriteConfiguration("EditorSettings", configData);
Здравствуйте, Amster, Вы писали:
A>По поводу шифрации конфига: есть стандарт XML Encryption, который позволяет шифровать отдельные ноды xml-документа, поэтому если одним конфигом пользуются несколько различных приложений,
класс зовется EncryptedXml
я так понимаю он действует как SignedXML, только вместо подписи отдельных нод шифрует их..
N>В общем, есть в app.config секция connectionStrings. Там у меня есть соответствующая N>информация о строке соединения с сервером СУБД. N>Встал вопрос о шифровании всего этого дела.
Хотелось бы поднять эту тему.
Может быть кто-нибудь знает утилиту для шифрования конфига консольного или вин-приложения наподобие aspnet_regiis -pef?
Здравствуйте, logos1014, Вы писали:
N>>В общем, есть в app.config секция connectionStrings. Там у меня есть соответствующая N>>информация о строке соединения с сервером СУБД. N>>Встал вопрос о шифровании всего этого дела.
L>Хотелось бы поднять эту тему. L>Может быть кто-нибудь знает утилиту для шифрования конфига консольного или вин-приложения наподобие aspnet_regiis -pef?
Всего конфига или достаточно определённой секции?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Спасибо конечно за ссылочки, но пользоваться гуглем мы тоже умеем
Вопрос стоит не в том, как закодировать секцию web.config'a (это можно сделать используя aspnet_regiis), а в том есть ли утилита для кодирования секции конфига консольного или винприложения.
Программный метод пожалуйста, не предлагать, потому что не хочется иметь в приложении стороннюю функциональность.
Здравствуйте, logos1014, Вы писали:
L>Вопрос стоит не в том, как закодировать секцию web.config'a (это можно сделать используя aspnet_regiis), а в том есть ли утилита для кодирования секции конфига консольного или винприложения. L>Программный метод пожалуйста, не предлагать, потому что не хочется иметь в приложении стороннюю функциональность.
Так что сложного в том, что бы написать приложение, которое принимает как аргумент путь к файлу и кодирует в нём некотурую секцию Написать с помощью API, на которое ссылка выше указана?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Написать с помощью API, на которое ссылка выше указана?
