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

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

bcrypt имеет встроенные соли для предотвращения атак радужной таблицы.

Он цитирует этой статье, который говорит, что в реализации OpenBSD bcrypt:

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

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

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

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

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

2 ответов


Это bcrypt:

генерировать случайную соль. Фактор "стоимости" был предварительно настроен. Соберите пароль.

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

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

Bcrypt работает очень похоже на более традиционные схемы, основанные на алгоритмах, таких как PBKDF2. Основным отличием является использование производного ключа для шифрования известного обычного текста; другие схемы (разумно) предположим, что функция вывода ключа необратима и сохраняет производный ключ напрямую.


хранится в базе данных, a bcrypt "хэш" может выглядеть примерно так:

$2a$10 $ vI8aWBnW3fID.ZQ4 / zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa

на самом деле это три поля, разделенные"$":

  • 2a определяет bcrypt версия алгоритма, которая была использована.
  • 10 - коэффициент затрат ; 210 используются итерации функции вывода ключа (чего, кстати, недостаточно. Я бы рекомендовал стоимость 12 или больше.)
  • vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa - это соль и шифрованный текст, Объединенный и закодированный в модифицированной базе-64. Первые 22 символа декодируются до 16-байтового значения для соли. Остальные символы-это зашифрованный текст, который необходимо сравнить для проверки подлинности.

этот пример взят из документация для Рубина кода Хейла реализация.


Я считаю, что эта фраза должна была быть сформулирована следующим образом:

bcrypt имеет соли встроенный в сгенерированный хэш для предотвращения атак "радужная" таблица.

на bcrypt сама утилита не поддерживает список солей. Скорее, соли генерируются случайным образом и добавляются к выходу функции, чтобы они запоминались позже (согласно реализация Java bcrypt). Другими словами, "хэш", сгенерированный bcrypt не просто хэш. Скорее это хэш и соли объединяются.