Множество итераций хеша: каждый раз добавлять соль?

Я долгое время использовал несоленый md5 / sha1, но так как этот метод не совсем безопасен (а со временем становится все менее безопасным), я решил переключиться на соленый sha512. Кроме того, я хочу замедлить генерацию хэша, используя много итераций (например, 100).

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

Добавлять каждый раз:

// some nice big salt
$salt = hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string . $salt, $raw);
}

return $string;

Добавлять один раз:

// add some nice big salt
$string .= hash($algorithm, $salt);

// apply $algorithm $runs times for slowdown
while ($runs--) {
    $string = hash($algorithm, $string, $raw);
}

return $string;

Сначала я хотел использовать вторую версию (добавить один раз), но затем нашел несколько сценариев, добавляющих соль каждый раз.

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

36
задан ircmaxell 28 May 2013 в 16:14
поделиться

3 ответа

Короче: Да. Перейдите к первому примеру... Хеш-функция может потерять энтропию, если будет возвращаться к самой себе без добавления исходных данных (сейчас я не могу найти ссылку, я буду искать).

Кстати, я поддерживаю многократное хэширование.

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

Да, он подвергает DOS-уязвимости, но также предотвращает атаки методом грубой силы (или, по крайней мере, делает их чрезмерно медленными). ). Существует абсолютно компромисс, но для некоторых выгоды превышают риски...

Ссылка (больше похожая на обзор) на весь процесс: Усиление ключей

Что касается вырождающихся столкновений, единственный источник Пока что я смог найти это обсуждение...

И еще несколько обсуждений на эту тему:

  1. Предложение HEKS
  2. Блог SecurityFocus о хешировании
  3. Документ об алгоритмах хэширования паролей Oracle

И еще несколько ссылок:

  1. PBKDF2 в Википедии
  2. Стандарт PBKDF2
  3. Подходящая ветка электронной почты
  4. Просто хэширования недостаточно. Сообщение в блоге

Там много результатов. Если хотите больше, погуглите растяжку хэша... Там масса полезной информации...

51
ответ дан 27 November 2019 в 05:57
поделиться

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

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

Как всегда, рекомендую прочитать это: Простого хеширования недостаточно

РЕДАКТИРОВАТЬ: Итеративное хеширование - совершенно допустимая тактика . Есть компромиссы, но они есть во всем. Если вас беспокоит время вычислений, почему бы просто не сохранить пароль в виде открытого текста?

6
ответ дан 27 November 2019 в 05:57
поделиться

Цель итеративного хеширования — максимально замедлить процесс. Так что вы можете сделать еще лучше: использовать разные соли для каждой итерации. Это можно сделать, снова и снова шифруя исходные данные на каждой итерации с фиксированным ключом и XOR с солевым значением.

0
ответ дан 27 November 2019 в 05:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: