Почему соль не помогла при использовании атаки по словарю
С этого сайта http://codahale.com/how-to-safely-store-a-password/:
Важно отметить, что соли бесполезны для предотвращения словарных атак или атак грубой силы.
Если соль бесполезна для предотвращения атаки по словарю, зачем использовать соль?
9 ответов
Для отдельных паролей это не имеет большого значения. Брутфорсинг несоленого пароля так же сложен, как и брутфорсинг соленого пароля. Вы просто пробуете ключи, пока не получите удар.
Разница возникает, когда паролей много, например, в просочившейся базе данных. Основная идея заключается в том, что часть необходимых вычислений может быть повторно использована при взломе многих паролей. Это делается путем построения радужного стола. Это требует больших вычислительных затрат, но после этого позволяет злоумышленнику сравнительно быстро взломать множество паролей. растрескивание N пароли с радужной таблицей намного быстрее, чем перебор N пароли индивидуально.
Если каждый пароль хешируется с индивидуальной солью, вы не можете повторно использовать информацию таким же образом. Вы все еще могли бы создавать радужные таблицы, но они могли бы использоваться только для одного пароля в базе данных, что делает их бесполезными. Итак, чтобы взломать N пароли, вы действительно должны перебор N пароли индивидуально, что обычно непрактично для злоумышленника.
Также для несоленных паролей и популярных алгоритмов хеширования вы можете просто загрузить предварительно рассчитанные радужные таблицы из Интернета. Таким образом, злоумышленнику даже не придется вычислять их самостоятельно. Он может просто скачать таблицу и найти пароль для конкретного хэша. Соль предотвращает это.
Несоленые хэши также имеют тот недостаток, что хэш пароля для двух пользователей с одинаковым паролем идентичен. Поэтому, если злоумышленник найдет несколько пользователей с одним и тем же хешем пароля, он должен взломать этот пароль только один раз.
В целях иллюстрации, скажем, вы используете 2-символьную строку для солей, которые могут быть случайным элементом из набора salts = {'00', '01', '02'...... '99'}
Формула, которую вы используете:
salt = salts[rnd(100)] # gets a random element from the set above, say '87'
password_hash = MD5(password + salt) # say the hash is 'dai480hgld0'
После этого вы сохраните хеш и соль в вашей базе данных, что-то вроде
+---------------------------+ | password_hash | соль | +---------------------------+ | dai480hgld0 | 87 | | sjknigu2948 | 23 | |, |, | |, |, | +--------------------+------+
Мы предполагаем, что в скомпрометированной системе злоумышленник имеет доступ к вашему коду, поэтому он знает, как вы вычислили ваши хэши.
Злоумышленник также получит доступ к вашей базе данных, поэтому у него есть все хэши паролей и соли.
Учитывая эту информацию, чтобы взломать ваш пароль (который имеет хэш: 'dai480hgld0'), он должен будет сделать следующее:
for word in dictionary_words #iterate over all the words in dictionary
for salt in salts #iterate over all possible salts (100 iterations)
password_hash = MD5(word + salt)
if password_hash == 'dai480hgld0'
print "The password is " + word
exit()
endif
next
next
Обратите внимание, что если бы вы не использовали соль вообще, алгоритм был бы
for word in dictionary_words #iterate over all the words in dictionary
password_hash = MD5(word)
if password_hash == 'dai480hgld0'
print "The password is " + word
exit()
endif
next
Из приведенных выше двух примеров кода очевидно, что добавление соли к паролю увеличивает количество попыток атаки методом перебора. В нашем случае, поскольку существует 100 возможных солей, вы заставили атакующего попробовать каждое слово с 100 солями.
Итак, сделаем вывод:
Соли хорошие. Они делают ваши пароли трудно взломать. Даже если ваши пользователи вводят слабые пароли, соль гарантирует, что полученные хеши не будут доступны для поиска. Например, его легко найти в хэше "3cc31cd246149aec68079241e71e98f6", который на самом деле является довольно сложным паролем и соответствует практически всем политикам паролей. Для взлома не требуется ни одной строки кода!
Соли не панацея. Они просто увеличивают время, необходимое взломщику для взлома ваших паролей. Однако, если у вас достаточно большое адресное пространство, значит, у вас все хорошо. Например, если у вас есть 32-символьная буквенно-цифровая строка в качестве соли - грубая сила действительно займет очень много времени.
- Медленные алгоритмы, такие как bcrypt, помогут вам в этом только потому, что они хорошо... "медленные". Для атаки методом грубой силы потребуется нереально много времени, чтобы разбить хэши, которые медленно вычисляются.
Если у "злоумышленника" есть хэш пароля (и соль), используемый вашим сайтом / приложением, он просто использует "соль" + "пароль".
Однако использование соли обеспечивает большую защиту от радужных таблиц (предварительно вычисленных хэш-таблиц), поэтому их все же стоит использовать.
Соли предотвращают мгновенный взлом из словаря через радужные таблицы; в статье и в дальнейшем говорится, что компромисс между ЦП и хранилищем теперь таков, что радужные таблицы не имеют смысла, и поэтому соли вам не помогут. И, конечно же, они никогда не помогали с атаками грубой силы.
Соль делает шифрование сильнее. Тем не менее, атаки по словарю не пытаются расшифровать хэш пароля, так что неважно, соль это или нет, они просто пробуют много паролей, пока один не сработает.
Это не совсем точно, так как в большинстве случаев это зависит от вашего предположения.
Основными предположениями являются:
- У нападающего есть соль
- вычисление хешей "на лету" выполняется довольно быстро (так как с солью ему нужно будет пересчитать все и не сможет использовать предопределенные списки)
- та же соль для каждого пользователя.
Теперь это не похоже на вопрос программирования, поэтому я просто дам вам некоторую информацию о солении и шифровании:
Целью засолки является помощь в односторонних функциях, таких как хеширование, которое широко используется в криптографии, часто при использовании паролей из-за сложности их угадывания и времени, которое требуется другим атакам, таким как атаки методом перебора, для их взлома.
Если вы хотите надежно хранить пароли, лучший способ - это определенно шифрование. Посмотрите шифрование в Википедии для получения дополнительной информации об этом.
Два комментария:
Обычные алгоритмы хеширования могут быть повторены. Нет необходимости использовать нестандартный алгоритм только потому, что вы хотите увеличить коэффициент работы.
Рекомендуется использовать соль, даже если вы используете метод медленного хэширования. Это не обязательно увеличит нагрузку на лучшую атаку, но остановит тривиальные атаки, если пользователь выберет пароль, идентичный паролю другого пользователя, другой учетной записи или старому паролю.
Это принадлежит security.stackexchange.com
Проблема заключается в вычислительной мощности в сочетании со скоростью алгоритма хеширования. В основном он передает bcrypt, который работает медленно.
Если хакер использует как хеш, так и соль, а также знает алгоритм, используемый для хэширования пароля, то взломать его - просто вопрос времени.
Если использовать очень быстрый алгоритм, то это время довольно мало. Если использовать чрезвычайно медленный алгоритм, тогда время, очевидно, намного больше, чтобы найти хит.
Что приводит нас к основной причине, почему мы в первую очередь хэшируем / солим вещи: чтобы выиграть время. Время, которое можно использовать для изменения всех перечисленных паролей, и время, чтобы связаться со всеми пользователями, чтобы сообщить им об этом в случае, если им нужно изменить свои пароли в других системах.
Причина, по которой мы используем соль, состоит в том, чтобы вынудить хакера построить радужный стол на сумму соли. Таким образом, одна таблица не может быть использована для взлома всех ваших паролей. Единственные причины сделать это - выиграть время и, мы надеемся, отговорить обычных хакеров от вложения дополнительных ресурсов в взлом их всех.
Хешированные пароли, независимо от используемого механизма, небезопасны в том смысле, что большинство людей принимают это слово. Безопасный не означает "никогда не может быть взломан". Скорее это означает, что "это будет дорого с точки зрения времени / усилий для взлома". Для большинства хакеров они хотят низко висящие фрукты, такие как только открытый текст. Для некоторых они пойдут на любую крайность, такую как построение массивных радужных таблиц на единицу соли, чтобы получить их все.
И, конечно же, в основе этого лежит то, легко ли идентифицируются какие-либо "супер" учетные записи пользователей в вашей пользовательской таблице. Для большинства систем достаточно просто взломать учетную запись типа системного администратора, и поэтому факт использования другого значения соли для пользователя не имеет значения. Умные будут просто беспокоиться об этом одном аккаунте.