Нужно ли солить хеш длинного случайного сессионного ключа в БД?
Если сессионный ключ случайный и имеет длину 256 бит (или больше), то ни радужнык таблицы, ни брутфорс хеша (который, естественно, тоже должен иметь не меньшую длину) не кажутся реальными, поэтому предполагаю, что для достаточно просто хранить хеш от сессионного ключа. Так ли это, или всё же лучше посолить? Какие возможные уязвимости я не учел? О том, что SQL-инъекция - не единственный способ перехвата сессии, я знаю,есть еще как минимум XSS и фишишг, но я рассматриваю сейчас сценарий похищения базы данных.
Не знаю что не учтено, но наличие соли позволит очень быстро инвалидировать все сессионные ключи.
Я бы предпочел добавить какую-то соль как минимум из-за этих соображений.
RidgeA, чтобы инвалидировать сессионный ключ достаточно удалить сессию из БД. Если нужно инвалидировать все сессии - truncate table sessions. Соль в этом случае не нужна и не поможет, так как предполагается уникальной для каждого ключа, как и в случае с паролями. Кроме того, не вижу смысла хранить невалидные сессии в БД. Или я Вас неправильно понял?
сессионный ключ -- это временный ключ на 2 недели, который генерится случайным образом и не зависит от пароля пользователя ни как. так у вас? если да, то зачем там что-то инвалидировать и солить?
teke teke, да именно так. Солить, как я уже понял, бессмысленно, а инвалидировать может понадобиться, например, если пользователь забыл поставить "чужой компьютер" и выити или украли ноутбук, на котором совершен вход на сайт. В таком случае кнопка "инвалидировать все сессии, кроме текущей", подобная аналогичной Вконтакте, может быть очень кстати. Хотя для опасных действий всё равно нужно подтверждение паролем, есть и безопасные, но неприятные при использовании злоумышленником возможности.
Зачем солить рандом? Соль нужна для рандомизации заведомо нерандомных величин, её наличие дает защиту от подбора исходного значения по хэшу через рандомные таблицы путем увеличения площади перебора в степени от длины. А если исходник и так длинный и случайный, его и так не подобрать. Не нужно.
Для чего вообще солят хэши? Против сливов БД: если хэши ушли, по ним сложно восстановить пароли.
• Если при подозрении на слив мы можем перегенерировать ключи или объявить их просроченными;
• Если ключи держатся где угодно, только не в БД;
• Если ключи настолько длинны и случайны, что сложновато будет обратить алгоритм объединёнными хакерскими силами
— то зачем?
Впрочем, не забывайте, что хэшируя, вы автоматически снижаете криптостойкость вашего алгоритма до длины хэша. А может, проще изначально делать ключи такой длины?
Простой
