Как «разоблачить» вы храните пароль в сеансе?

Question

Я делаю сайт с использованием Python и Flask и задаюсь вопросом о чем-то, что для меня очень важно.

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

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

варианты я думал так далеко:

• Незашифрованная: Логически самый худший вариант.
• Hashed: Например, сохраните sha256(password) на сеанс. Это тоже нехорошо, потому что крекеры могут использовать словарные таблицы для получения незашифрованного пароля.
• Salted & Hashed: Например, за исключением sha256(password+hash). Это самый безопасный из трех вариантов, но это будет копия записи в базе данных, и мне это не кажется хорошей идеей. Взломщик мог сравнить свой пароль с его собственным хешем и, возможно, выяснить, как соли и хеши создаются для всей базы данных. Я не уверен, что это действительная проблема, но я думаю, что знающий пользователь в Stackoverflow сможет мне сказать. ;)
• Salted & Hashed, с базой данных, сохраняющей рекурсивно хэшированную строку: По сути, это кажется хорошим вариантом, но я читал, что рекурсивно хэширование пароля всегда является плохим.

Итак, какой из них рекомендуется? Может быть, пятый, о котором я не думал? Обратите внимание, что эту переменную необходимо использовать для проверки учетных данных пользователя, поэтому мы не можем просто использовать ее с другой солью или так.

Answer 1

Зачем вам нужно хранить пароль пользователя в сеансе вообще? Я не вижу в этом никакой особой необходимости, и это просто создает потенциальный риск для безопасности без каких-либо оснований.

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

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

Пс. Очевидно, что независимо от того, что вы делаете, убедитесь, что ваши идентификаторы сеансов сгенерированы с использованием криптографически безопасного генератора случайных чисел (например, Crypto.Random.random) и что они достаточно длинны, чтобы быть неопровержимыми (по меньшей мере 64 бит = 16 шестнадцатеричных цифр, хотя 128 бит лучше).Если по какой-либо причине вы не можете сделать это, альтернативой является создание такого случайного токена самостоятельно, сохраните его как в сеансе, так и в файле cookie и убедитесь, что токены сеанса и файлов cookie совпадают перед использованием любые фактические данные сеанса.