Как реализовать защиту паролем для отдельных файлов?

Question

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

У меня есть стратегия, которая кажется работоспособной и логичной, исходя из того, что я знаю (чего, вероятно, достаточно, чтобы быть опасной), но я понятия не имею, действительно ли это хороший дизайн или нет.Ну, скажите мне:это безумие?Есть ли лучший/лучший способ сделать это?

• Шаг 1:Пользователь вводит пароль в виде открытого текста, например.«Мой СложныйПароль»
• Шаг 2:Приложение хеширует пароль пользователя и использует это значение в качестве симметричного ключа для шифрования/дешифрования файла данных.например«MyDifficultPassword» -> «HashedUserPwdAndKey».
• Шаг 3:Приложение хеширует хешированное значение, полученное на шаге 2, и сохраняет новое значение в заголовке файла данных (т. е.незашифрованную часть файла данных) и использует это значение для проверки пароля пользователя.например«HashedUserPwdAndKey» -> «HashedValueForAuthentication»

По сути, я экстраполирую обычный способ реализации паролей веб-сайтов (то есть, когда вы не используете OpenID), который заключается в хранении (соленого) хеша пароля пользователя в вашей БД и никогда не сохранении фактического пароля. .Но поскольку я использую хешированный пароль пользователя в качестве ключа симметричного шифрования, я не могу использовать то же значение для аутентификации.Поэтому я хеширую его еще раз, рассматривая его как другой пароль, и сохраняю дважды хешированное значение в файле данных.Таким образом, я могу перенести файл на другой компьютер и расшифровать его, просто введя свой пароль.

Так является ли этот дизайн достаточно безопасным, или безнадежно наивным, или где-то посередине?Спасибо!

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

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

Означает ли это, что я могу хранить значение соли в том же месте/файле, что и хешированный ключ, и при этом быть более безопасным, чем если бы я вообще не использовал соль при хешировании?Как это работает?

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

Answer 1

Генерация ключей

Я бы рекомендовал использовать признанный алгоритм, такой как PBKDF2, определенный в ПККС №5 версия 2.0 для генерации ключа из вашего пароля.Он похож на описанный вами алгоритм, но способен генерировать более длинные симметричные ключи для использования с AES.Вы сможете найти библиотеку с открытым исходным кодом, которая реализует генераторы ключей PBE для различных алгоритмов.

Формат файла

Вы также можете рассмотреть возможность использования Синтаксис криптографического сообщения в качестве формата вашего файла.Это потребует некоторого изучения с вашей стороны, но, опять же, существуют существующие библиотеки, которые можно использовать, и это открывает возможность более плавного взаимодействия с другим программным обеспечением, например почтовыми клиентами с поддержкой S/MIME.

Проверка пароля

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

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

Криптографическая соль

Соль помогает предотвратить заранее рассчитанные атаки по словарю.

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

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

Так что не обязательно хранить соль в секрете.Достаточно гарантировать, что у злоумышленника нет заранее вычисленного словаря, соответствующего этой конкретной соли.

Answer 2

Как сказал Нияз, этот подход звучит разумно, если вы используете качественную реализацию сильных алгоритмов, таких как ША-265 и АЕС для хеширования и шифрования.Кроме того, я бы рекомендовал использовать Соль чтобы уменьшить возможность создания словаря всех хешей паролей.

Конечно, читая Брюс Шнайер's Прикладная криптография тоже никогда не ошибается.

Answer 3

Если вы используете надежный алгоритм хеширования (SHA-2) и надежный алгоритм шифрования (AES), этот подход подойдет вам.

Answer 4

Почему бы не использовать библиотеку сжатия, поддерживающую файлы, защищенные паролем?Раньше я использовал защищенный паролем zip-файл, содержащий XML-содержимое :}

Answer 5

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

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