Шифрование / дешифрование в .NET - PullRequest
2 голосов
/ 14 сентября 2010

Я ищу безопасный способ шифрования и дешифрования строки в проекте Visual Studio (в C #). Я обнаружил, что есть нативные классы DES, но они недостаточно безопасны. У вас есть предложения?

ОБНОВЛЕНИЕ: Хорошо, тогда возникает вопрос: какой самый безопасный способ зашифровать / расшифровать строку без особых хлопот (иначе говоря, нужно устанавливать внешние инструменты и т. Д. С внешней библиотекой все в порядке). И куда поместить секретный «ключ» (достаточно ли безопасно компилировать значение внутри кода?).

Обновление № 2 Если я использую что-то вроде этого кода для сохранения зашифрованной строки в файле конфигурации:

using System.Security.Cryptography;
using System.Security;
byte[] encrypted = ProtectedData.Protect(StrToByteArray("my secret text"), null, DataProtectionScope.LocalMachine);
byte[] derypted = ProtectedData.Unprotect(encrypted , null, DataProtectionScope.LocalMachine);

Это достаточно безопасно? Я предполагаю, что с параметром «LocalMachine» вместо параметра «Пользователь» кто-то может просто написать приложение в .net, поместить его на компьютер и выполнить для расшифровки зашифрованной строки. Так что, если я хочу, чтобы это было более безопасно, у меня должен быть файл конфигурации, различный для каждого пользователя? Я правильно понимаю?

Ответы [ 6 ]

7 голосов
/ 14 сентября 2010

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

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

Если вы шифруете содержимое, предназначенное только для чтения на одном компьютере или пользователем одного домена, рассмотрите API защиты данных (DPAPI) . Он забирает ключ шифрования из ваших рук - он использует учетные данные пользователя Windows в качестве ключа.

У меня есть немного больше деталей в другом ответе здесь: Постоянное хранение зашифрованных данных с использованием .Net

Относительно вашего второго редактирования ( Достаточно ли хорош DataProtectionScope.LocalMachine? ); эта запись в блоге MSDN хорошо ее обобщает:

Установка области действия DataProtectionScope.CurrentUser шифрует данные так, чтобы только в данный момент вошедший в систему пользователь может расшифровать Это. Переключение на DataProtectionScope.LocalMachine позволяет любому процессу, запущенному на текущая машина для расшифровки данных. Это может быть полезно на сервере сценарий, где нет ненадежных логины к машине, но для рабочая станция общего назначения с использованием Шифрование LocalMachine почти эквивалентно использованию без шифрования в все (так как любой, кто вошел в систему, может получить по данным).

1 голос
/ 14 сентября 2010

Если я правильно прочитал ваше обновление, вы, в основном, хотите скрыть некоторую строковую константу от системного администратора, слоняющегося вокруг вашей сборки.

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

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

Если вам нужна дополнительная безопасность, почти единственная возможность - не передавать пользователю соответствующие части кода. Создайте веб-сервис, содержащий секретные части вашего приложения, и защитите соединение с помощью SSL / TLS.

1 голос
/ 14 сентября 2010

Он также имеет AES .

0 голосов
/ 14 сентября 2010

Использование хорошо протестированной и принятой библиотеки тоже хорошая идея ...

http://www.bouncycastle.org/csharp/

0 голосов
/ 14 сентября 2010

Это зависит от вашего определения безопасности достаточно.Вы можете использовать тройной DES..Net также имеет собственный класс Rijandel.Это достаточно безопасно?http://www.obviex.com/samples/Encryption.aspx

0 голосов
/ 14 сентября 2010

Попробуйте использовать AesManaged.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...