почему соль не поможет при использовании атаки по словарю

Question

С этого сайта http://codahale.com/how-to-safely-store-a-password/:

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

Если соль бесполезна для предотвращения атаки словаря, зачем использовать соль?

Answer 1

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

Answer 2

Если «атакующий» имеет хеш-пароль (и соль), который используется вашим сайтом/приложением, он просто перетаскивает «соль» + «пароль».

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

Answer 3

Это принадлежит на security.stackexchange.com

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

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

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

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

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

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

И, конечно же, под этим понимается, легко ли идентифицировать любые «супер» учетные записи пользователей в вашей пользовательской таблице. Для большинства систем просто взломать тип учетной записи sys admin достаточно, и поэтому факт использования различного значения соли для пользователя несуществен. Умные будут просто беспокоиться об этой одной учетной записи.

Answer 4

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

основное предположение являются:

1. Атакующий имеет соль вычисление хэшей «на лету»
2. выполняются довольно быстро (как с солью ему нужно будет пересчитать все и не будут иметь возможность использовать готовые списки)
3. та же соль для каждого пользователя.

Answer 5

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

Answer 6

Теперь это не похож на вопрос программирования, так что я просто дам вам некоторую информацию о посоле и шифровании:

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

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

Answer 7

Два комментария:

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

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

Answer 8

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

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

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

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

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

Answer 9

Для целей иллюстрации, что вы используете строку 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  | salt| 
+---------------------------+ 
| 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 солями.

Итак, вывод:

• Соли хороши. Они делают ваши пароли жесткими для взлома. Даже если ваши пользователи вводят слабые пароли, соль гарантирует, что результирующие хэши не будут искажаться. Например, его легко сделать google «3cc31cd246149aec68079241e71e98f6», который на самом деле является довольно сложным паролем и будет отвечать почти всем политикам паролей. Все еще трещина требует не одной строки кода!

• Соли не являются панацеей. Они просто увеличивают время, затрачиваемое взломщиком на принудительные пароли. Однако, если ваше солевое адресное пространство довольно большое, вы довольно хороши. Например, если у вас есть 32 символа буквенно-цифровой строки в качестве соли - грубая сила действительно займет очень много времени.
  

• Медленные алгоритмы, такие как bcrypt, помогают вам в этом отношении только потому, что они хорошо ... «медленные». Для атаки грубой силы потребуется нереалистично долго ломать хэши, которые медленно вычисляются.