.Net Encryption

Question

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

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

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

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

4. Поскольку я использую ClickOnce, я мог бы зашифровать конфиденциальную информацию в коде или встроить ее, потому что ClickOnce не обнаружит изменения, если версия # не изменится. Поэтому, если мне нужно перекомпилировать, если я изменяю строку подключения, точка app.config отключается. Какие другие подходы я могу использовать, используя конфигурационный файл, для обеспечения защиты строк подключения на сервере, клиенте и между ними?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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