Почему соли имеют фиксированные длины?

Question

Я думал, что причина использовать переменные, случайные строки в качестве солей - заставить атакующего искать каждую соль, прежде чем использовать его радужный стол на хеше. Это занимает много времени.
Но большинство разработчиков, похоже, используют фиксированные размеры для своих солей. Если вы посмотрите на размер одной соли, которую знаете, потому что большинство паролей хранятся вместе с солью, разве вы не могли бы просто отрезать солевую длину от каждого пароля, а затем использовать свой радужный стол?
Я не вижу, как это было бы слишком большим усилием, и это заставляет меня задаться вопросом, почему я должен использовать переменную соль. Потому что единственная информация, которую требует атакующий, - это размер одной соли, а затем ему больше не нужно искать солей. Разве рандомизированный размер не был бы намного более безопасным?
Изменчивость и рандомизация действительно кажутся мне «безопасностью сквозь неясность», потому что так легко обходить друг друга, если вы знаете метод и единственная причина его реализации - вызвать некоторые моменты путаницы. Или я ошибаюсь?

Answer 1

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

Публичная соль делает ее более трудоемкой, чтобы взломать список паролей. Тем не менее, он не усложняет словарные атаки при взломе одного пароля. - Salt (cryptography).

Простой способ создания хорошей соли заключается в том, чтобы генерировать большое (скажем, 128 случайных бит) значение из генератора криптографических случайных чисел. Это будет тривиально гарантировать, что соли будут иметь одинаковую длину, но есть insane количество уникальных значений, которые могут быть представлены 128 бит.

Поскольку хэш генерируется с использованием оригинальной «длинную» соли, используя обрезанную соль позже просто дать неверный хэш , когда указав первоначальный пароль - это не делает его легче найти хэш столкновение. (Выбор «медленный» хэш как Bcrypt еще одно требование для хорошего хэшированном дизайна пароля.)

Если злоумышленник был в состоянии обмануть систему, чтобы использовать небольшой диапазон значений соли (или даже фиксированное значение соли), то соли теряют свойство «достаточно уникального».

---

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