Мой первый вопрос: я слышал, что хеширование строки 2 раза (например, sha1(sha1(пароль))), потому что второй хеш имеет фиксированную длину, это правда??
Мой второй вопрос, что безопаснее? (var1 и var2 — две строки):
Если это 1-й, стоит ли это затрат на производительность?
Дважды хешируя строку, вы увеличиваете риск коллизий, что плохо с точки зрения безопасности.
Вместо бесконечного количества входных данных, ведущих к 2128 возможных выходных данных, у вас будет 2128 возможных входных данных, ведущих к, возможно, менее 2128 выходы.
Использование соли и перца перед хешированием, по крайней мере, сохраняет исходные данные бесконечными возможностями. Двойное хэширование увеличивает время выполнения вашего скрипта и увеличивает риск коллизий, если вы не поддерживаете источник бесконечного ввода.
sha1(sha1(password)) — это плохо. Что касается OP: да, sha1(var1 + sha1(var2)) лучше и, как правило, стоит (обычно не имеет значения!) Затраты на производительность. (И я имел в виду дополнительные коллизии выше; извините за мои повторные правки.)
- person Sz.; 27.05.2014
Ни один из них не является очень безопасным. Не изобретайте велосипед. Для этого был разработан HMAC; в частности, предпринимаются шаги (заполнение и т. д.), чтобы избежать проблем с определенными недостатками в определенных алгоритмах хеширования, которые плохо взаимодействуют с вышеупомянутыми «простыми» реализациями.
Кроме того, двойное хеширование бесполезно для повышения безопасности. Подумайте: в лучшем случае вы сопоставите одно случайное значение с другим случайным значением. Однако в случае коллизии два результирующих значения из второго хэша равны, вы потеряли безопасность из-за коллизии. То есть вы никогда не сможете избавиться от коллизии таким образом, но вы можете ее получить.
Тем не менее, существующие атаки на прообразы могут не работать против двойного хеширования... но! Они еще могут работать. Я не могу сказать, что, и если вы спрашиваете об этом здесь, вы, вероятно, тоже. Конечно, атаки на столкновение, которые на сегодняшний день представляют собой единственное практическое применение MD5, не защищены от двойного хеширования.
Лучше всего придерживаться проверенных алгоритмов, которые выдержали десятилетия анализа, потому что с помощью криптографии слишком легко сделать что-то, что выглядит безопасным, но на самом деле таковым не является.
Сомневаюсь, что это добавит безопасности. Это увеличит время выполнения вашего скрипта, но не добавит безопасности хешу. Помните, что когда кто-то пытается взломать ваш хэш, ему не нужно находить точное значение var1 и var2, ему нужно только найти то, которое приводит к тому же хэшу.
Я не эксперт в криптографии, но, насколько я знаю, вы не получите никакой защиты от многократного хеширования значения, кроме замедления процесса. Таким образом, если вы хэшируете 1000 раз, вы сделаете атаку (например, атаку по словарю) в 1000 раз медленнее, но это совершенно не имеет значения в случае хеширования один или два раза.
Использование только одной и без соли позволяет легко решить эту проблему.
Существует много больших таблиц, содержащих тонны этих хэшей, поэтому один хэш без соли можно решить практически без ничего.
Добавление второго хэша также мало поможет, потому что эти таблицы уже существуют с сохраненными значениями.
Динамическая соль, добавленная к паролю, поможет гораздо больше, чем несколько хэшей. Множественные хэши на самом деле мало что добавляют к этому.
У меня такое ощущение, что вы строите кирпичную стену со стальной дверью, а остальные стены сделаны из фанеры. Другими словами, вы можете добавить столько безопасности, сколько захотите, к хешированию паролей, но все равно будут гораздо более простые способы взломать вашу систему. Я думаю, что гораздо лучше использовать широкий подход к безопасности, чем слишком беспокоиться о таких вещах.
Будет ли var1 + var2 одинаковым в ожидаемой ситуации? Я имею в виду, что в этом случае первое предложение должно быть в порядке, потому что вы избежите коллизии хеширования. О том, стоит ли цена, это вопрос, на который вы должны ответить. Стоит ли избегать столкновения.
Что касается алгоритма sha, предполагается, что он действительно искажает результаты. Таким образом, его многократное применение не должно давать лучших результатов, а его применение к «более случайному» вводу не должно давать лучших результатов.
Многократное хеширование строки усложнит задачу злоумышленника в случае атаки по словарю, делая его «намного длиннее» для грубой силы. Ваш первый вопрос не ясен, но несколько хэшей не менее безопасны, потому что второй хеш имеет фиксированную длину.
Но важнее, чем множественный хэш, использование соли необходимо для лучшая безопасность.
Что касается вашего второго вопроса, я бы сказал, что не очень просто сказать, какой из двух вариантов самый безопасный, я думаю, что варианта 2 действительно достаточно.
