Какая польза от «случайной» соли над «уникальной» солью?

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

Мой вопрос: в чем преимущество этого, а не просто использовать uniqid() ? Разве не нужно просто убедиться, что соли, используемые для хэшей, отличаются друг от друга, а не случайными? Не будет ли использование действительно случайной соли на самом деле хуже, чем использование уникальной соли, поскольку она потенциально может вызвать столкновения, а uniqid () не будет?

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

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

Конечно, если криптографически безопасный генератор случайных чисел доступен вам в вашей выборке (например, RNGCryptoServiceProvider в .NET), вы бы выбрали для этого более предсказуемые шаблоны. Я посмотрю, смогу ли я найти хорошие прецеденты или документы по этому поводу.

В PHP uniqid() вычисляет свой результат на основе текущего времени. Это помогает убедиться, что значения уникальны, потому что два раза не два раза, однако это не работает на нескольких серверах, поскольку оно чисто основано на времени. Использование чего-то временного – это плохо, потому что количество разных значений, которые могут быть созданы uniqid() , очень ограничено. Предполагая, что PHP используется в течение 25 лет, он вычисляет до 7.89e + 14 микросекунд, которые прошли, и поэтому было бы получено одинаковое количество значений для uniqid() .

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

 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ 

Это означает, что у нас есть 64 разных персонажа для использования соли длиной 22 символа, которая вычисляет примерно 5.44e + 39 различных комбинаций.

Таким образом, в основном, пытаясь сделать что-то уникальное, оно на самом деле менее уникально, чем если бы использовался случайный источник.

Майк, как я сказал в своем другом ответе, я бы не подумал, что это проблема с солями, но если вас действительно беспокоит истинная / псевдослучайность, вы можете использовать цифры из random.org. См. Разницу , а и посмотрите, как получить истинное случайное число в PHP .

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

(Обсуждение OT: Я утверждал, что я не вижу большого преимущества использования соли для хранения паролей – как только злоумышленник получает соль для конкретного хэшированного пароля, он может делать словарные атаки в любом случае … он будет медленнее, потому что злоумышленник должен перефразировать словарь для каждой соли паролей, но .. md5 () быстро, как черт, и если атака занимает 5 минут или половину дня, какая разница … Я не чувствую себя намного безопаснее с солью, чем без.)

EDIT – обсуждение : соль делает большую разницу во времени, требуемом для взлома паролей, но не используйте md5 () для хеширования паролей! Используйте очень медленную функцию хэширования, такую ​​как bcrypt (), или, если вам нужно использовать md5 (), назовите ее много тысяч раз!