Что мешает хакеру просто удалить соль из хеша и сравнить его с несоленым хешем?
я Коды Хейл«Как безопасно хранить пароль» заявляет, что:
В bcrypt есть встроенные соли, чтобы предотвратить атаки радужного стола.
Он цитируетЭта бумага, который говорит, что в реализации OpenBSDbcrypt
:
OpenBSD генерирует 128-битную соль bcrypt из ключевого потока arcfour (arc4random (3)), заполненного случайными данными, которые ядро собирает по времени устройства.
Я не понимаю, как это может работать. В моей концепции соли:
Он должен быть разным для каждого сохраненного пароля, поэтому для каждого из них необходимо создать отдельную радужную таблицу.Он должен быть где-то сохранен, чтобы его можно было повторять: когда пользователь пытается войти в систему, мы предпринимаем попытку пароля, повторяем ту же процедуру с использованием соли и хэша, которую мы делали при первоначальном сохранении пароля, и сравниваемКогда я использую Devise (менеджер входа в Rails) с bcrypt, в базе данных нет столбца соли, поэтому я запутался. Если соль случайная и нигде не хранится, как мы можем надежно повторить процесс хеширования?
Короче говоря,Как bcrypt может иметь встроенные соли?