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

В статье Coda Hale «Как безопасно хранить пароль» утверждается, что:

В bcrypt встроены соли для предотвращения атак с радужного стола.

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

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

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

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

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

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

Это bcrypt:

Генерация случайной соли. Фактор «стоимость» был предварительно настроен. Собери пароль.

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

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

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

Хранящийся в базе данных bcryptхеш может выглядеть примерно так:

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

На самом деле это три поля, разделенные символом «$»:

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

Этот пример взят из документации по реализации Ruby в Coda Hale.

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

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

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

Чтобы сделать вещи еще яснее,

Регистрация / Направление входа ->

Пароль + соль шифруется ключом, сгенерированным из: стоимости, соли и пароля. мы называем это зашифрованное значение cipher text. затем мы добавляем соль к этому значению и кодируем ее с помощью base64. добавив стоимость к нему, и это полученная строка из bcrypt:

$2a$COST$BASE64

Это значение сохраняется в конце концов.

Что нужно сделать злоумышленнику, чтобы найти пароль? (другое направление <-)

В случае, если злоумышленник получит контроль над БД, он легко расшифрует значение base64 и сможет увидеть соль. соль не секрет. хотя это случайно. Тогда ему нужно будет расшифровать cipher text.

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

Это из документации по интерфейсу PasswordEncoder от Spring Security,

 * @param rawPassword the raw password to encode and match
 * @param encodedPassword the encoded password from storage to compare with
 * @return true if the raw password, after encoding, matches the encoded password from
 * storage
 */
boolean matches(CharSequence rawPassword, String encodedPassword);

Это означает, что нужно сопоставить rawPassword, который пользователь введет снова при следующем входе в систему, и сопоставить его с зашифрованным паролем Bcrypt, который хранится в базе данных во время предыдущего входа в систему / регистрации.