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

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

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

Вопрос в том, как сохранить эту комбинацию пользователя + пароль в потенциально незащищенной базе данных?

Я не совсем понимаю, что мне следует разоблачить.

Предположим, я создаю расширенный ключ следующим образом:

 соль = случайная строка из 32 символов (это нормально?)
 key = hash (пароль usr + соль)
 от 1 до 65000
   key = hash (ключ + пароль usr + соль)

Должен ли я хранить [пользователь открытого текста], [расширенный ключ] и [соль] в базе данных?

Кроме того, что я должен использовать для шифрования (с AES или Blowfish) некоторых файлов с использованием нового пароля каждый раз? Должен ли я генерировать новую соль и создавать новый расширенный ключ (пароль, сохраненный в памяти программы + соль)? И в этом случае, если я храню зашифрованный файл в базе данных, возможно, я должен хранить соль. База данных совпадает с тем, где я храню комбинацию пользователя + пароль.

Файл может быть дешифрован, только если кто-то может сгенерировать ключ, но он не знает пароль. Правильно ?

Я использую Python с PyCrypto, но это не очень важно, общий пример – это просто отлично. Я прочитал несколько подобных вопросов, но они не очень явные.

Огромное спасибо!

2 Solutions collect form web for “Хранение пользователя и пароля в базе данных”

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

Хранение паролей: пароли должны быть хэшированы с использованием алгоритма растягивания ключей . Как правило, вы хотите использовать библиотеку, а не реализовывать ее самостоятельно. Ключевые алгоритмы растяжения предназначены для пережевывания процессорных циклов, поэтому неплохо оценить их с помощью хорошего кода 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 .

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

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

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