Стоит ли хранить имя хеш-функции в БД при хешировании паролей?

Question

Что касается сохранения версии хеш-версии пароля пользователя, я сохраняю в БД хешированный соленый пароль и соль, использованную до его хеширования.

Должен ли я также сохранить в БД имяАлгоритм, используемый для хеширования посоленного пароля (например, SHA1 или MD5 [я не собираюсь использовать MD5!]), поэтому в случае, если кто-то обнаружит нарушение в алгоритме, который я использую, я мог бы переключиться на использование другого алгоритма для будущих пользователей?

Примечание: я не говорю об алгоритме, используемом для генерации случайного хэша.

Answer 1

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

Обратите внимание, что вы должны использовать что-то вроде PBKDF2 для хэширования ваших паролей, а не просто соленый хеш.

Answer 2

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

• Вы хотите переключиться на лучшую альтернативу хеширования, если обнаружена слабость
• Вы не храните незашифрованные пароли (что, если вы, у вас есть большие проблемы)

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

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

Answer 3

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

Существует веб-сайт keylength.com , на котором содержится сводка наиболее важных рекомендаций по обеспечению информационной безопасности в вычислительной технике. В настоящее время выбранная хеш-функция должна иметь длину 160 бит или более - чем больше, тем лучше.

И если вы ищете универсальный формат, вы можете использовать модульный crypt формат , который содержит идентификатор хеш-функции, использованную соль, дайджест, и дополнительную информацию (например, коэффициент стоимости) в форме:

$<id>$[<parameters>$]<salt><digest>

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