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