хэш (hash ()) против соленого хэша

Question

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

Когда люди говорят о соленых хешах, всегда используют это таким образом hash(password . salt) или даже hash(hash(password) . salt).

Я не знаю, зачем использовать соль, и добавить дополнительную запись для каждого пароля для хранения соли? Почему бы нам просто не использовать hash(hash(password)) или даже hash(hash(hash(password)))?

Разве безопаснее добавлять соль? или просто чувство быть более сложным?

Answer 1

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

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

Answer 2

Для простоты давайте представим, что все используют цифры в качестве своих паролей.

Если все используют 8 цифр в качестве пароля, это 100 000 000 возможностей. Если вы пытаетесь сломать систему, вам нужно хэшировать все эти возможности. Если у вас есть «хэш хэша хэша», вам все равно нужно просто хэшировать эти 100 000 000 возможностей - просто несколько более сложным способом.

Теперь давайте представим, что у нас также есть 4-значная соль. Теперь, вместо 100 000 000 возможностей, есть 1 000 000 000 000 ... мы дали потенциальному злоумышленнику в 10 000 раз больше работы, чем просто в 3 раза больше работы.

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

РЕДАКТИРОВАТЬ: Просто для ясности, учитывая, что соль предоставляется также в виде простого текста, у вас все равно будет только 100 000 000 возможностей для попытки атаковать любой хеш . Тем не менее, это означает, что после использования этих возможностей для одного пароля у злоумышленника не будет никакой полезной информации для атаки на другой пароль. Без соли злоумышленник может создать словарь с 100 000 000 возможностей, а затем узнать все пароли в базе данных, учитывая только их хэши. Другими словами, соли помогают предотвратить массовые атаки. Они также означают, что вы не можете перегенерировать словарь: чтобы эффективно атаковать один пароль, вы должны знать соль заранее. Без соли вы можете вычислить хеш каждого возможного пароля, прежде чем получите доступ к самим хешам.

Answer 3

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

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

Ваша идея повторения хэша все еще хороша, но соль вам тоже нужна.Если вы сделаете это:

function hashPassword(password, salt) {
    result = hash(salt . password)
    for (i = 0; i < 1000; i++) {
        result = hash(salt . result)
    }
    return result
}

, то вы заставите злоумышленника работать в 1000 раз тяжелее с незначительным эффектом для законных пользователей.Обратите внимание, что злоумышленники могут проверять миллионы паролей-кандидатов каждую секунду на одном компьютере низкого уровня - хэш-функции предназначены для быстрой работы.Этот цикл 1000 итераций может превратить выполнимую атаку в одну, которая займет 100 лет или более.Когда компьютеры ускоряются за 18 месяцев, просто измените число итераций на 2000.

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

Answer 4

Итерация хеша и использование соли повышает безопасность хеширования пароля. Но они защищают от совершенно разных атак.

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

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

Answer 5

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

Answer 6

Соль - это значение для сайта или пользователя. Это означает, что для получения паролей злоумышленник должен иметь как доступ к базе данных, так и знать соль.

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

Соли, специфичные для сайта, очень мало влияют на безопасность сайта. Как сказано в комментариях, наличие комбинации специфичных для сайта и специфических для пользователя солей может значительно повысить безопасность по сравнению только с сайт-специфической солью.

Несколько лет назад я задал здесь на stackoverflow вопрос о хранении пароля, который может быть вам полезен. См. Безопасный хеш и соль для паролей PHP .

Answer 7

Ничто не мешает создать таблицу Rainbow для дважды хешированных паролей.

Answer 8

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