Почему не хэшируют email и логин как пароль? В чем минусы?
Изучаю тему того как лучше хранить пароли в бд. Узнал, что все современные сайты хранят хэш пароля в бд, а затем, пропускают текст, который ввел пользователь через ту же хэш функцию и сравнивают хэши. Но во всех примерах авторизации хэшируют только пароль. Email или логин хранят в открытом виде. Что будет если хэшировать и логин и email, а при проверке также, как и пароль пропускать через хэш функцию? Тогда злоумышленник сможет получить доступ только к хэшам, но не к телефону или email, который может использоваться на других сайтах. Почему так не делают? БД будет занимать больше места? Или так не делают потому что хэш фунции медленные? Какие минусы такого подхода?
Ответы (1 шт):
На это есть несколько причин:
1) Необратимость
Если хранить логины и почту в виде хеша, то и узнать эти самые логин и почту будет невозможно. А значит по почте не получится найти ваш логин (например когда вы его забыли и восстанавливаете через почту), так же, как и по логину не получится найти почту (нельзя будет зайти по логину в аккаунт).
2) Коллизии
Множество разных исходных могут вести к одному и тому же хешу (если мы говорим про классический, часто-используемый хеш). Это не страшно для паролей, так как разные пароли, ведущие к одному и тому же хешу, никак друг другу не мешают, однако почта и логин должны быть уникальны на пользователя. И даже если коллизия имеет минимальные шансы на возникновение, риск всё ещё присутствует, особенно если в базе данных хранятся миллионы пользователей.
3) Вычислительные ресурсы
Хорошие хэш функции в любом случае будут использовать дополнительные ресурсы, а когда речь идёт про миллионы, а то и миллиарды записей в БД, то любая мелочь, дающая дополнительную нагрузку, превращается в заметную трату ресурсов
Да и в принципе нет ни одной хорошей причины хешировать логины, почты и другие подобные данные