Что мешает хакеру просто удалить соль из хеша и сравнить его с несоленым хешем?

я Коды Хейл«Как безопасно хранить пароль» заявляет, что:

В bcrypt есть встроенные соли, чтобы предотвратить атаки радужного стола.

Он цитируетЭта бумага, который говорит, что в реализации OpenBSDbcrypt:

OpenBSD генерирует 128-битную соль bcrypt из ключевого потока arcfour (arc4random (3)), заполненного случайными данными, которые ядро ​​собирает по времени устройства.

Я не понимаю, как это может работать. В моей концепции соли:

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

Когда я использую Devise (менеджер входа в Rails) с bcrypt, в базе данных нет столбца соли, поэтому я запутался. Если соль случайная и нигде не хранится, как мы можем надежно повторить процесс хеширования?

Короче говоря,Как bcrypt может иметь встроенные соли?

Ответы на вопрос(2)

Ваш ответ на вопрос