Есть ли у хеш-соли какое-либо иное применение, кроме как для предотвращения атак с радужного стола?

Question

Я слышал, что единственная цель соли состоит в том, чтобы предотвращать атаки радужного стола, но наверняка она должна иметь большую ценность, чем эта? Разве это не помешает атаке по словарю? А как насчет грубой силы, будет ли соль здесь полезной? И не могли бы вы объяснить, почему, пожалуйста?

Во-вторых, предположим, у меня был алгоритм, который брал микротайм, 128-символьную соль и случайное число от 1 до 10 миллиардов и складывал их вместе. Будет ли это обеспечить высокий уровень безопасности? Ибо даже если злоумышленник знал одну из этих деталей, мне кажется, что вычислить остальное все равно будет невозможно в вычислительном отношении. Правда ли, что?

Спасибо

Ben

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

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

$salt = "some random characters I made up";
hash('sha256', microtime(true).$salt.mt_rand(1000,9999));

Я знаю, что это только 1000-9999 вместо миллиардов, упомянутых выше.

Еще раз спасибо.

Answer 1

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

Атаки по словарю и грубой атакой - это одно и то же. Соление не останавливает их, так как ваш алгоритм валидации похож на

plain-text-passwd = 'secret provided by user'
salt = getSalt(username) //looks the salt value up in database based on the users username
hash-password-in-db = getPassword(username) // looks up hashed password bassed on users username
if(hash(plain-text-passwd + salt) == hash-password-in-db) //if true, password is correct

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

Во-вторых, предположим, у меня был алгоритм ...

Это бессмысленно, вам нужно хранить всю эту информацию в таблице информации о пользователях, где 5-значное солт-значение служит той же цели.

Answer 2

Радужная таблица - это метод оптимизации, который можно использовать как для атак по словарю, так и для атак методом перебора.

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

Ваш второй пример на самом деле просто более длинная соль с некоторыми частями с меньшей энтропией. Вызывает беспокойство то, что вы различаете «случайное число» и «соль», поскольку соль должна быть случайным одноразовым числом.