Хранение пользователя и пароля в базе данных

Крипто трудно понять, хорошо, что вы задаете вопросы.

Хранение паролей: пароли должны быть хэшированы с использованием алгоритма растягивания ключей . Как правило, вы хотите использовать библиотеку, а не реализовывать ее самостоятельно. Ключевые алгоритмы растяжения предназначены для пережевывания процессорных циклов, поэтому неплохо оценить их с помощью хорошего кода C. Если вы работаете в Linux-системе с glibc , вы можете использовать модуль crypt.crypt (read man crypt ):

 import crypt encrypted = crypt.crypt(password, '$6$' + salt + '$') 

Это возвращает строку ASCII, которую вы можете безопасно хранить в своей базе данных. ( $6$ – расширение glibc, которое использует функцию растяжения ключа на основе SHA-512. Если у вас нет этого расширения, не используйте crypt.crypt ). (Редактирование: алгоритм очень похож на тот, который вы задавали в своем вопросе. Однако наилучшей практикой обычно является то, что библиотека может делать это, а не сворачивать ваши собственные.)

Шифрование файлов: не делайте этого самостоятельно. Установите GnuPG (или scrypt, bcrypt, ncrypt, что у вас есть). Есть несколько вещей, которые могут легко ошибиться при разработке собственного способа шифрования файлов. Эти инструменты используют надлежащие функции деривации ключей, хэши аутентификации и режимы шифрования без какой-либо дополнительной настройки. Это не библиотеки Python, а исполняемые файлы, поэтому вам придется написать оболочку, которая использует модуль subprocess .

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

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

Цель соли состоит в том, чтобы сделать грубую силу или диктовку атаками намного сложнее. Вот почему он более безопасен, если хранить отдельно, чтобы избежать того, у кого есть как хэш-пароли, так и соответствующие соли.