Как хранить, проверять и использовать ключ для шифрования/дешифрования в Python и SQLite

Введение: я пытаюсь попрактиковаться в Python и Crypto, написав простой локальный менеджер паролей с помощью Python и SQLite. Проблема начинается при регистрации. Пользователь вводит мастер-пароль, который я храню в таблице в SQLite после хэширования 1 раз с помощью SHA256. Во время входа в систему я беру пароль времени входа в систему и повторно хэширую его с помощью SHA256 и сравниваю оба. Если они совпадают, я вхожу. Теперь любые данные, которые пользователь шифрует или расшифровывает, выполняются с использованием того же хэша пароля, который хранится в БД. Кстати, я делаю шифрование/дешифрование с помощью AES. Теперь у SQLITE нет мер безопасности по умолчанию, поэтому любой, кто имеет доступ к БД, может просто расшифровать все данные, просто используя хешированный пароль, поскольку это также сам КЛЮЧ. Им даже не нужно брутфорсить/подбирать пароль. Я обнаружил, что мне нужно использовать Key Stretching и PBKDF2 для создания KEY или НЕСКОЛЬКИХ КЛЮЧЕЙ для шифрования/дешифрования.

Теперь я пытался сделать это в течение нескольких дней без везения. Все, что мне нужно сделать, это сгенерировать сверхзащищенный HASH с использованием PBDKF2, но как я собираюсь получить из него ключ Enc/Dec? потому что если я использую тот же ключ для enc/dec, то бесполезно использовать алгоритм и запускать hmac поверх hmac, если результат сам по себе является мастер-ключом, используемым для Enc/Dec. Никто даже не должен отменить это. Я также слышал, что PBDFK2 может генерировать вторичные ключи из мастер-ключа, которые я могу использовать для enc/dec, но я копался в официальной документации pycryprpto, cryptodome и так и не понял, как это делается на самом деле. Даже если я учту тот факт, что это возможно, магия PBKDF заключается в рандомизации солей и hmac ing снова и снова, поэтому никогда значение, возвращаемое для одного и того же набора строк, никогда не будет возвращаться одинаковым. Итак, как я могу проверить, равен ли хэш пароля времени входа сохраненному хешу пароля? . Второе, что я пробовал, это проверить время входа в систему и сохраненный хэш БД, предоставив те же соли, и даже если они верны, что я должен использовать в качестве 16-, 24- или 32-байтового ключа для фактического шифрования и расшифровки данных? Я не нашел, где исследовать об этом. . . . Существует также реддит-версия этого. Если это поможет: https://www.reddit.com/r/learnprogramming/comments/cken8f/how_to_securely_store_a_master_password_hash_onto/


person C0DEV3IL    schedule 12.08.2019    source источник
comment
Пожалуйста, сократите свой вопрос до того, что существенно, и помните: несколько строк кода могут сказать больше, чем тысяча слов.   -  person Klaus D.    schedule 12.08.2019
comment
Я могу сказать в псевдокоде. Но проблема в том, как/что мне делать со сложным хэшированным ключом pbkdf2? Ну псевдокод прост. При запуске -> Регистрация -> Пользователь вводит мастер-ключ -> db.save - SHA256 (Мастер-ключ) при входе в систему -> Запросить мастер-ключ -> сравнить ключ db.master с sha256 (user_key) -> если верно -> войти. Используйте тот же ключ для enc/dec. Проблема -> Поскольку сохраненный хеш в БД ЯВЛЯЕТСЯ КЛЮЧОМ, не нужно его взламывать, просто используйте хэш для расшифровки данных. Вопрос, мне ответили, что мне нужно использовать PBKDF2. Ну КАК именно?   -  person C0DEV3IL    schedule 12.08.2019


Ответы (1)


Чтобы ответить на ваши потребности, вы можете использовать пример, предоставленный известным менеджером паролей, например. KeePass (см. https://keepass.info/help/base/security.html ).

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

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

person Lou_is    schedule 19.08.2019