Как password salt помогает против атаки rainbow table?

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

Я видел много учебников, предлагающих использовать соль следующим образом:

$hash =  md5($salt.$password)

причина в том, что хэш теперь сопоставляется не с исходным паролем, а с комбинацией пароля и соль. Но скажи $salt=foo и $password=bar и $hash=3858f62230ac3c915f300c664312c63f. Теперь кто-то с радужной таблицей может отменить хэш и придумать вход "foobar". Затем они могли попробовать все комбинации паролей (f, fo, foo,... oobar, obar, bar, ar, ar). Для получения пароля может потребоваться еще несколько миллисекунд, но не больше.

другое использование, которое я видел, находится в моей системе linux. В /etc/shadow хэшированные пароли фактически сохраняются С соль. Например, соль "foo" и пароль " bar " будут хэшировать к этому:$foo$te5SBM.7C25fFDu6bIRbX1. Если хакер каким-то образом смог заполучить этот файл, я не вижу, какой цели служит соль, так как обратный хэш te5SBM.7C25fFDu6bIRbX как известно, содержит "foo".

Спасибо за любой свет, который любой может пролить на это.

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

10 ответов


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

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

в поймите первый, представьте себе один файл пароля, который содержит сотни имен пользователей и паролей. Без соли я мог бы вычислить " md5 (попытка[0])", а затем Сканировать файл, чтобы увидеть, появляется ли этот хэш где-нибудь. Если соли присутствуют, то я должен вычислить " md5 (salt[a]. попытка[0])", сравните с записью A, затем " md5(salt[b]. попытка[0])", сравнить с записью B и т. д. Теперь у меня есть n раз столько работы, где n число Логинов и паролей содержится в файле.

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

но если файл пароля засолен, то таблица rainbow должна содержать "соль". пароль" предварительно хешируется. Если соль достаточно случайна, это очень маловероятно. Вероятно, у меня будут такие вещи, как "hello", "foobar" и "qwerty" в моем списке часто используемых, предварительно хэшированных паролей (таблица rainbow), но у меня не будет таких вещей, как "jX95psDZhello" или "LPgB0sdgxfoobar" или "dZVUABJtqwerty". Это сделало бы Радужный стол непомерно большой.

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


другие ответы, похоже, не касаются вашего непонимания темы, поэтому здесь идет:

два различных использования соли

Я видел много учебников, предлагающих использовать соль следующим образом:

$hash = md5($salt.$password)

[...]

другое использование, которое я видел, находится в моей системе linux. В/etc / shadow хэшированные пароли фактически хранятся вместе с солью.

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

безопасность хэш

теперь кто-то с радужной таблицей может отменить хэш и придумать вход "foobar".

[...]

С обратной хэш te5SBM.7C25fFDu6bIRbX это известно, что содержит "foo".

невозможно отменить хэш как таковой (по крайней мере, теоретически). Хэш "foo "и хэш" saltfoo " имеют ничего в общем. Изменение даже одного бита на входе криптографической хэш-функции должно полностью изменить выход.

это означает, что вы не можете построить радужную таблицу с общими паролями, а затем "обновить" ее с помощью соли. Нужно взять соли с начало.

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

качество соль

но сказать $salt=foo

" foo " будет очень плохой выбор соли. Обычно вы используете случайное значение, закодированное в ФОРМАТ ASCII.

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

нападение

если хакер каким-то образом смог заполучить этот файл, я не вижу, какой цели служит соль,

Радуга таблица атака всегда должен /etc/passwd (или какая-либо база данных паролей используется), или как бы вы сравнили хэши в таблице rainbow с хэшами фактических паролей?

что касается цели: предположим, злоумышленник хочет построить радужную таблицу для 100 000 часто используемых английских слов и типичных паролей (подумайте "секрет"). Без соли ей пришлось бы подсчитать 100 000 хэшей. Даже с традиционной солью UNIX из 2 символов (каждый из 64 выбор:[a–zA–Z0–9./]) ей придется вычислить и сохранить 4,096,000,000 хэшей... довольно улучшение.


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

таким образом, хорошим значением соли будет случайное 128-битное или более длинное целое число. Это то, что делает атаки rainbow-table неудачными. Используя другое значение соли для каждого сохраненного пароля, вы также гарантируете, что радуга таблица, построенная для одного конкретного значения соли (как это может быть, если вы популярная система с одним значением соли), не дает вам доступ ко всем паролям сразу.


еще один отличный вопрос, со многими очень продуманными ответами -- +1 к так!

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

почему это важно?

представьте себе базу данных паролей в крупной компании на северо-западе США. Предполагаю, что это содержит 30 000 записей, из которых 500 имеют пароль bluescreen. Предположим далее, что хакеру удается получить этот пароль, скажем, прочитав его по электронной почте от пользователя в ИТ-отдел. Если пароли несоленые, хакер может найти хэшированное значение в базе данных, а затем просто сопоставить его, чтобы получить доступ к другим учетным записям 499.

соление паролей гарантирует, что каждая из 500 учетных записей имеет уникальный (salt+password), генерирующий Различный хэш для каждого из них, и тем самым уменьшая нарушение до одной учетной записи. И будем надеяться, что, вопреки всей вероятности, любой пользователь, достаточно наивный, чтобы написать пароль открытого текста в сообщении электронной почты, не имеет доступа к недокументированному API для следующей ОС.


Я искал хороший метод для применения солей и нашел эту превосходную статью с образцом кода:

http://crackstation.net/hashing-security.htm

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

для хранения пароля:

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

для проверки пароля :

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

причина, по которой соль может сделать атаку радужной таблицы неудачной, заключается в том, что для n-бит соли радужная таблица должна быть в 2^n раз больше размера таблицы без соли.

ваш пример использования " foo " в качестве соли может сделать радужный стол в 16 миллионов раз больше.

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


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

такие атаки неэффективно в случае, когда пароли содержат гораздо больше символов и не соответствуют общим форматам на основе слов. Пользователь с надежным паролем для начала не будет уязвим для этого стиля атаки. К сожалению, многие люди не выбирают хорошие пароли. Но есть компромисс, вы можете улучшить пароль пользователя, добавив к нему случайный мусор. Так что теперь вместо" hunter2 "их пароль может стать эффективно" hunter2908!fld2R75{R7/; 508PEzoz^U430", который является гораздо более сильным паролем. Однако, поскольку теперь вам нужно сохранить этот дополнительный компонент пароля, это снижает эффективность более сильного составного пароля. Как оказалось, такая схема по-прежнему имеет чистую выгоду, так как теперь каждый пароль, даже слабые, больше не уязвимы для одной и той же предварительно вычисленной хэш-таблицы / радуги. Вместо этого каждая хэш-запись пароля уязвима только для уникальной хэш-таблицы.

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

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

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


одна из целей соления-победить предварительно вычисленные хэш-таблицы. Если у кого-то есть список миллионов предварительно вычисленных хэшей, они не смогут найти $1$foo$te5SBM.7C25fFDu6bIRbX1 в их таблице, хотя они знают хэш и соль. Им все равно придется применить грубую силу.

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

обе эти цели по-прежнему даже если эти соли общедоступны.


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

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

таким образом, хакер может использовать это в своих интересах, а не используя только грубую силу. Он не будет искать пароли, такие как aaa, aab, aac... но вместо этого используйте слова и общие пароли (например, имена Властелина колец! ;))

Итак, если мой пароль-Леголас хакер можно попробовать и угадать это с помощью "нескольких" попыток. Однако если мы солим пароль и он становится fooLegolas хэш будет отличаться, поэтому атака словаря будет неудачной.

надеюсь, что это поможет!


Я предполагаю, что вы используете функцию PHP - - - md5 () и переменные $ preceded --- тогда вы можете попробовать посмотреть эту статью теневой пароль HOWTO специально 11-й пункт.

кроме того, вы боитесь использовать алгоритмы дайджеста сообщений, вы можете попробовать реальные алгоритмы шифрования, такие как те, которые предоставляются mcrypt модуль или более сильные алгоритмы дайджеста сообщений, такие как те, которые предоставляют mhash модуль (sha1, sha256, и другие.)

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