Безопасное сохранение пароля в программном коде?

Мое приложение использует класс RijndaelManaged для шифрования данных. В рамках этого шифрования я использую объект SecureString, загруженный с паролем, который получает преобразование в массив байтов и загружается в ключ объекта RajindaelManaged во время выполнения.

Вопрос, который у меня есть, - это хранилище этой SecureString. Введенный пароль пользователя может быть введен во время выполнения, и это может быть "безопасно" загружено в объект SecureString, но если пароль пользователя не введен, мне нужно что-то по умолчанию.

Итак, в конечном счете, quesiton сводится к:

Если мне нужно, чтобы какой-либо известный массив строк или байтов загружался в объект SecureString каждый раз, когда мое приложение запускается, как это сделать? "Зашифрованные" данные, в конечном счете, дешифруются другим приложением, поэтому, даже если ни один введенный пользователем пароль не указан, мне все же нужны данные, которые нужно зашифровать, пока они переходят из одного приложения в другое. Это означает, что у меня не может быть пароль по умолчанию случайным, потому что другое приложение не сможет его правильно расшифровать.

Одним из возможных решений, о которых я думаю, является создание dll, который выплескивает только одну кодовую фразу, а затем я использую эту кодовую фразу и запускаю ее через пару различных функций хэширования/реорганизации во время выполнения, прежде чем я в конечном итоге отправлю ее в secureString объект. Будет ли это достаточно безопасным?

Правка Для ясности *: Зашифрованные данные передаются через файлы между машинами. Подумайте об этом как о файле Zip, который всегда имеет пароль, по умолчанию считается, что пользователь ничего не вводил.

Ответ 1

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

Смотрите этот Pidgin FAQ для той же точки в другом контексте.

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

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

Ответ 2

Позвольте мне сначала решить ваш последний вопрос.

"Это будет достаточно безопасно?"

Единственное, на что можно ответить, это вы. Никто здесь не знает, что означает "достаточно безопасно" в контексте вашего приложения.

Вы создаете приложение, чтобы вести дневник девочек-подростков? Конечно, это было бы "достаточно безопасно".

Вы создаете приложение для шифрования информации или аутентификации для защищенных систем военного класса? Нет, даже не закрывай.

Вы можете полагаться только на один тип безопасности, если вы намерены хранить пароль в своем исходном коде и, следовательно, исполняемый файл, и это безопасность безвестности.

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

Однако мне интересно что-то. Вы говорите: "Я должен по умолчанию что-то". Это оно? Вы пытаетесь сохранить значение по умолчанию для строки безопасного пароля в исходном коде? Как насчет "THISISNOTAPASSWORD"?

Ответ 3

Эрик Липперт Вы хотите солить с этим? (оригинальное сообщение в блоге)

Также прочитайте его сообщение в Используйте правильный инструмент для задания, где он заканчивает следующими советами:

0) Если возможно, просто не ходите туда. Шифрование чрезвычайно сложно получить правильно и часто является неправильным решением в первую очередь. Используйте другие методы для решения ваших проблем безопасности.

1) Если проблема является ненадежным клиентом, тогда не создавайте решение безопасности, которое требует доверять клиенту.

2) Если вы можете использовать готовые части, сделайте это.

3) Если вы не можете использовать готовые части и вам нужно использовать криптосистему, тогда не используйте криптосистему, которую вы не полностью понимаете.

4) Если вам нужно использовать криптосистему, которую вы не полностью понимаете, то по крайней мере не используйте ее для решения проблем, которые она не предназначена для решения.

5) Если вам нужно использовать криптосистему для прокачки по деревьям, то по крайней мере не позволяйте предположительно враждебному клиенту выбрать сообщение, которое зашифровано. Выберите маркер самостоятельно. Если токен должен включать информацию от клиента, то каким-то образом его дезинфицируйте; требуют, чтобы он был только прямым текстом ASCII, вставлял случайные пробелы и т.д.

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

7) Не используйте ту же пару ключей для шифрования исходящих сообщений, как и для защиты входящих сообщений. Получите пару ключей для каждой логически другой операции, которую вы собираетесь выполнять.

8) Шифруйте сообщения в обоих направлениях.

9) Подумайте о наличии механизма аннулирования, так что, как только вы узнаете, что Ева нападает на вас, вы можете по крайней мере отозвать ее лицензию. (Или вы можете аннулировать известную лицензию и т.д.)

Ответ 4

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

Ответ 5

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

Быстрый поиск в Google дал мне this Код проекта, в котором говорится об использовании хранилища сертификатов Windows в .Net