.Net Шифрование

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

Используя шифрование на уровне машины, никто не может получить доступ к моему серверу, чтобы написать небольшую программу .Net для чтения содержимого строк подключения?
Если я развертываю свое приложение на компьютерах пользователей в корпоративной среде, а приложение имеет строки подключения в файле конфигурации, как я могу убедиться, что только мое приложение может его расшифровать? Этот сценарий особенно интересен в сценарии развертывания ClickOnce. Я читал о людях, хранящих конфигурацию, незашифрованную на сервере издателя, и шифрование на уровне машины, когда приложение загружается, устанавливается и выполняется в первый раз. Это звучит так неправильно для меня - строки подключения, незащищенные проводом через провод, и сидят без защиты в течение короткого промежутка времени между загрузкой и выполнением приложения.
Могу ли я иметь открытый и закрытый ключ, подписывать свое приложение, шифровать файл конфигурации с помощью ключа, а когда пользователь его выполняет, дешифрование будет возможно только из подписанного приложения?
Так как я использую ClickOnce, я мог бы зашифровать конфиденциальную информацию в коде или встроенном, потому что ClickOnce не обнаружит изменения, если не изменится версия #. Итак, если мне нужно перекомпилировать, если я изменю строку подключения, точка app.config будет отключена. Какие другие подходы я могу использовать, вне зависимости от файла конфигурации, для обеспечения защиты строк соединения на сервере, клиенте и между ними?

Ответ 1

Да. Секреты, зашифрованные с помощью машинного ключа, могут быть дешифрованы любым процессом с доступом к машинной клавише. Секреты, зашифрованные с помощью ключа пользователя, могут быть дешифрованы любым процессом, запущенным одним и тем же пользователем.
Это невозможно. Все противоположные утверждения - это змеиное масло. Для приложения вам нужен секрет, чтобы что-то расшифровать. Нет никаких известных схем скрытия секретности внутри приложения. Существуют различные схемы обфускации, но ничего пуленепробиваемого. Лучшее, что вы можете сделать, это поднять планку.
Нет. Либо приложение имеет секретный ключ, чтобы расшифровать что-то, и в этом случае вы вернетесь к пункту 2, либо ваше приложение имеет открытый ключ, и в этом случае любой может расшифровать тот же секрет, поэтому вы в основном выполняете проверку конфигурации (было не подделано), но конфигурация не является секретной.
Вы не можете безопасно развернуть встроенные секреты в приложении. Это всего лишь вопрос о том, насколько высока цена, если ваш защищенный актив (секрет) стоит того, а хакер получит его.

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

Ответ 2

Хороший вопрос на самом деле,

Вы не можете быть уверены, что никто не расшифрует вашу строку подключения (или пароль). Конечно, вы можете зашифровать его, но люди смогут декомпилировать ваше приложение и посмотреть, какой алгоритм шифрования вы используете и какой ключ вы используете для дешифрования вашей строки/пароля. Может быть, это больше похоже на экстремальный сценарий, но это возможно (я был злым взломщиком в студенческие годы:)). Поэтому, если вы боитесь такого сценария, вы должны защитить свое приложение, сделать его сложнее разобрать. Это тема для другого обсуждения, но, например, вы можете использовать Dotfuscator или другой хороший обфускатор - это будет сделать его более трудным для взломщика, чтобы понять, что происходит внутри вашего приложения.
Таким образом, одним из возможных решений может быть" шифрование строки подключения + использование обфускатора", но, как я уже сказал, он не даст вам 100% защиты.

Ответ 3

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

Я бы определенно попытался использовать механизм операционной системы. Когда вы работаете в чистой среде Windows с MS-SQL, вы должны использовать интегрированную защиту вместо пользователя/пароля. Другие базы данных также могут иметь схожие возможности.
Другой (более слабый) вариант заключается в том, чтобы обеспечить файл cleartext с настройками безопасности операционной системы - только пользователь получает доступ к файлу. Однако вы и ваши пользователи должны доверять администраторам. В этом случае вы также должны использовать симметричное шифрование. Но см. Мои первые аргументы - это будет не очень безопасно.

Ответ 4

Gustavo, вы можете реализовать это (это мой план для моего приложения, основанного на логине).

Пользователь вводит учетные данные в .Net приложении. Учетные данные передаются на серверное приложение .php, которое использует их для входа в базу данных и получения ключа и передачи его обратно в приложение .Net. Затем ключ используется в строковых закодированных строках подключения в приложении .Net, чтобы обеспечить полный доступ к базе данных.