Надежно хранить пароль в коде программы? - PullRequest
10 голосов
/ 15 июня 2010

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

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

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

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

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

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

Ответы [ 5 ]

8 голосов
/ 15 июня 2010

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

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

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

РЕДАКТИРОВАТЬ: Если она передается на другой компьютер, возможно, вы можете жестко закодировать открытый ключ , а затем расшифровать другую машину с соответствующим закрытымключ.

6 голосов
/ 15 июня 2010

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

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

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

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

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

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

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

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

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

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

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

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

6 голосов
/ 15 июня 2010

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

"Будет ли это достаточно безопасно?"

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

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

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

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

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

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

2 голосов
/ 15 июня 2010

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

Быстрый поиск в Google дал мне эту статью проекта кода, в которой рассказывается об использовании Магазина сертификатов Windows в .Net

2 голосов
/ 15 июня 2010

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

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