Лучший способ для хеширования «запомнить меня» печенье токенов

Question

Я пытаюсь реализовать «запомнить» особенность, следуя инструкциям, представленная здесь: The definitive guide to form-based website authentication и здесь: http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

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

Ищет хороший алгоритм хеширования, я нашел эту рекомендованную технику, используя Bcrypt: https://stackoverflow.com/a/6337021/488666

Я попробовал его и обнаружил, что с количеством раундов предложенным (15) приводит к очень медленное время обработки (хэш 2,3 с + проверка 2,3 с на процессоре Intel Core 2 Duo E8500 + 4 ГБ)

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

Считаете ли вы, что меньше раундов (например, 7, что снижает время обработки до 10 мс + 10 мс) будет достаточно?

Answer 1

Цитирование The definitive guide to form-based website authentication:

НЕ ХРАНИТЬ УСТОЙЧИВУЮ ВХОД COOKIE (лексема) в базе данных, ТОЛЬКО HASH ЕГО! Входной токен является эквивалентом пароля, поэтому, если злоумышленникполучил свои руки от своей базы данных, он может использовать токены в в любой учетной записи, так же, как если бы они были cleartext login-password комбинаций. Следовательно, используйте сильное соленое хеширование (bcrypt/phpass) при хранении постоянных токенов входа.

Я согласен с первым смелым предложением, но не последним.

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

Но хешированная строка не является паролем, а случайной строкой. Поэтому маловероятно, чтобы любой стол радуги мог получить любую изначально хешированную строку. Я даже предполагаю, что я просто мог бы использовать базовый вызов hash('sha256', $randomString) для этого, цель состояла в том, чтобы иметь разные значения для токена в БД и в файле cookie.