Вопрос по salt, authentication, security, hash – Защищены ли хешированные и защищенные пароли от атак по словарю?

9

Я понимаю, что соли делают один и тот же хэш пароля для разных значений. Однако соли обычно хранятся в базе данных с паролем. Итак, давайте скажем, что я атакующий, вот как я могу использовать атаку по словарю против соли (обратите внимание, что в этом примере я не пишу 128-битные хеши или соли для краткости):

user_pw = 'blowfish'

Given:
email = '[email protected]'
hash = '1234567890'
salt = '0987654321'

function attack(){
  for each(word in dictionary)
    md5( word * salt ) == hash ? cracked_one(email, word)
}

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

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

Это правильный анализ? Какие-нибудь предложения для лучшей безопасности?

Спасибо!

Ваш Ответ

5   ответов
10

только предварительно рассчитанные атаки по словарю. В частности защищает от радужных столов (http://en.wikipedia.org/wiki/Rainbow_table), а также гарантирует, что взлом пароля одного пользователя не позволит автоматически взломать любого пользователя, который разделяет этот пароль.

В статье, на которую я ссылаюсь, упоминаются некоторые способы улучшения соления, в том числе усиление ключа (http://en.wikipedia.org/wiki/Key_strengthening).

Для некоторых это может быть очевидным, но следует отметить, что соление защищает от атак на хеш-значения, а не на сам пароль (т. Е. Злоумышленник уже имеет доступ к базе данных, хеш-значение передается в виде простого текста и т. Д.).
Оно может. Моя точка зрения была немного другой - ОП упомянул, что он, похоже, не предотвращает атаки по словарю. Я хотел прояснить, что любой словарь может атаковать ваш интерфейс, не беспокоясь о солях. Соление защищает способ хранения таких паролей.
кажется, что большая разница в том, что при использовании соли злоумышленнику в основном придется вычислять новый словарь или радужную таблицу для каждой соли или пользователя. Вы знаете, сколько времени нужно, чтобы вычислить радужную таблицу на 1 миллион слов? (не ищу точного ответа здесь) Tony
@dsatch Salting защищает от получения пароля из хэша и последующего использования этого пароля на других сайтах. Или, скорее, это делает это намного дороже, чтобы сделать это.
Не лично, ноproject-rainbowcrack.com/table.htm говорит, что вам не нужно делать свои собственные: вы можете скачать их. Хуже того, взломщики используют преимущества графического процессора NVidia Cuda для ускорения своих усилий. Эти радужные столы огромны, даже по современным стандартам, поэтому их умножения всего на 4G (32 бита) достаточно, чтобы совершенно невозможно хранить даже все возможные радужные таблицы, забывая о стоимости генерации.
0

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

Возможно, при достаточной силе и времени нет защиты от атак грубой силы. Однако использование пароля, которого нет ни в одном словаре, является достаточным для защиты вас от любой атаки по словарю.
Хороший момент, но обучение пользователей выбору безопасных паролей само по себе является усилием
1

атака по словарю будет эффективной.

Чтобы защититься от этого:

Make sure your passwords aren't subject to dictionary attacks. Make sure your password file (/etc/shadow) is readable only by root.
Конечно, но интегрировано ли это в систему смены пароля?
Если файл pam_cracklib.so включен в стек PAM, он интегрируется.
Это может быть очевидный вопрос задним числом, но есть ли возможность отклонить пароли, найденные в словаре? Я также не спрашиваю конкретно о вариантах Unix.
@Steven Sudit: вы можете использовать cracklib для этой цели
1

оем словаре, а затем запустить новый словарь для вашего списка паролей.

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

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

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

Я не уверен, что это правильно. Грубая сила подразумевает последовательный или случайный поиск в возможном пространстве паролей. С солью злоумышленник все еще может применить соль и хеш к словарю, но он должен выбрать одно значение соли, чтобы сделать это, и он не будет заранее иметь это значение произвольно, поэтому ему придется вычислить это на лету.
@ Стивен, ты прав, я исправил недоразумение
4

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

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

В принципе,прочитай это.

Настраиваемый подход к хэшу звучит так же, как усиление ключа. Любой хеш можно настроить таким образом, запуская его снова и снова.
Да, это ключевое усиление и связанная техника. Хорошая статья, хотя, особенно часть о SRP. Благодарю.

Похожие вопросы