Надежно сохраните пароль в коде программы?
Мое приложение использует класс RijndaelManaged для шифрования данных. Как часть этого шифрования, я использую объект SecureString, загруженный паролем, какой get's преобразовывается в массив байтов и загрузился в Ключ объекта RajindaelManaged во времени выполнения.
Вопросом, который я имею, является устройство хранения данных этого SecureString. Введенный пароль пользователя может быть введен во времени выполнения, и это может быть "надежно" загружено в объект SecureString, но если введенный пароль никакого пользователя дан, то я должен принять значение по умолчанию к чему-то.
Таким образом, в конечном счете quesiton сводится:
Если у меня должен быть некоторый известный массив строк, или массив байтов для загрузки в SecureString возражают каждый раз моему выполнению приложения, как я делаю это? "Зашифрованные" данные в конечном счете дешифрованы другим приложением, поэтому даже если введенный пароль никакого пользователя указан, мне все еще нужны данные, которые будут зашифрованы, в то время как это идет от одного приложения до другого. Это означает, что у меня не может быть пароля по умолчанию быть случайным, потому что другое приложение не смогло бы правильно дешифровать его.
Одно возможное решение я думаю, состоит в том, чтобы создать dll, который только выкладывает единственный пароль, затем я использую тот пароль и работаю, это посредством нескольких других хеширований/реорганизаций функционирует во времени выполнения, прежде чем я в конечном счете подам его в объект secureString. Это было бы достаточно безопасно?
Редактирование Для clarity*: зашифрованные данные передаются через файлы между машинами. Думайте о нем как о zip-файле, который всегда имеет пароль, по умолчанию принят, если ничто непосредственно не вводится пользователем.
5 ответов
Нет смысла в симметричном шифровании со строкой, жестко закодированной в вашем исполняемом файле. Это только создаст ложное чувство безопасности. Никакое хеширование не исправляет эту схему.
См. этот FAQ по Pidgin для того же самого момента в другом контексте.
Мне непонятно, почему вы думаете, что вам нужно шифровать обмен данными между приложениями. Если эта связь является локальной для машины, то я не вижу необходимости в шифровании, особенно в шифровании, которое не зависит от пользователя. Это схема DRM?
РЕДАКТИРОВАТЬ: Если она передается на другую машину, возможно, вы можете жестко закодировать открытый ключ , а затем расшифровать другую машину с помощью соответствующего закрытого ключа.
Позвольте мне сначала ответить на ваш последний вопрос.
«Это будет достаточно безопасно?»
Единственный, кто может ответить, это вы. Здесь никто не знает, что означает «достаточно безопасный» в контексте вашего приложения.
Вы создаете приложение для ведения дневника девочек-подростков? Конечно, это было бы «достаточно безопасно».
Вы создаете приложение для шифрования информации или аутентификации для защищенных систем военного уровня? Нет, даже близко.
Вы можете полагаться только на один тип защиты, если вы намереваетесь сохранить пароль в исходном коде и, следовательно, в исполняемом файле, а именно на защиту от неизвестности .
Если ваша проблема в том, что вы не можете или не хотите хранить пароль в исходном коде, то перенос его в отдельную dll ничего не решает, вы просто переместили проблему в другой проект.
Однако меня кое-что интересует. Вы говорите: «Я должен сделать что-то по умолчанию». Это оно? Вы пытаетесь сохранить значение по умолчанию для защищенной строки пароля в исходном коде? Как насчет "ЭТОГО ПАРОЛЯ"?
Эрика Липперта ( исходное сообщение в блоге )
Также прочтите его сообщение на Используйте подходящий инструмент для работы , где он заканчивает следующими советами:
0) Если возможно, просто не ходи туда. Шифрование чрезвычайно сложно сделать правильно, и зачастую это в первую очередь неправильное решение. Используйте другие методы для решения ваших проблем с безопасностью.
1) Если проблема заключается в ненадежном клиенте, не создавайте решение безопасности, которое требует доверия к клиенту.
2) Если вы можете использовать готовые детали, сделайте это.
3) Если вы не можете использовать готовые части и действительно должны использовать криптосистему, тогда не используйте криптосистему, которую вы не полностью понимаете.
4) Если вам приходится использовать криптосистему, которую вы не совсем понимаете, то, по крайней мере, не используйте ее для решения проблем, для решения которых она не предназначена.
5) Если вам нужно использовать криптосистему, чтобы скользить по деревьям, то, по крайней мере, не позволяйте предположительно враждебному клиенту выбирать зашифрованное сообщение. Выбирайте токен самостоятельно. Если токен должен включать информацию от клиента, то как-нибудь его очистите; требовать, чтобы это был только простой текст ASCII, вставлять случайные пробелы и т. д.
6) Если вы должны разрешить клиенту выбирать токен, не шифруйте сам токен. Подпишите криптографически безопасный хэш токена. Злоумышленнику гораздо сложнее выбрать токен, который производит желаемый хеш.
7) Не используйте ту же пару ключей для шифрования исходящих сообщений, как для защиты входящих сообщений.Получите пару ключей для каждой логически отличающейся операции, которую вы собираетесь выполнить.
8) Шифруйте сообщения обоими способами.
9) Подумайте о наличии механизма отзыва, чтобы, как только вы узнали, что Ева атакует вас, вы могли, по крайней мере, отозвать ее лицензию. (Или вы можете отозвать заведомо скомпрометированную лицензию и т. Д.)
Эта статья о защите строк подключения SQL должна быть так же применима для хранения зашифрованных паролей, когда вы позволяете ОС обрабатывать шифрование начального числа для вашего дешифрования.
Мне кажется, что, возможно, вам следует использовать решение PKI вместо шифрования / дешифрования. Если у вас есть другое приложение, которому необходимо использовать зашифрованные данные, вы можете иметь пару ключей для этого приложения и предоставить открытый ключ приложению, которое выполняет шифрование. Таким образом, вы по-прежнему сохраняете свои данные в безопасности, но не вводите кучу дополнительного кода, который в конечном итоге не дает такой большой защиты.
Быстрый поиск в Google дал мне эту статью Code Project, в которой рассказывается об использовании хранилища сертификатов Windows в .Net