Почему соли делают словарные атаки "невозможными"?

Возможный дубликат:
Нужна помощь в понимании соли соли

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

Я понимаю процесс и сам реализую его в некоторых своих проектах.

s =  random salt
storedPassword = sha1(password + s)

В базе данных, которую вы храните:

username | hashed_password | salt

Каждая реализация соления, которую я видел, добавляет соль либо в конце пароля, либо начинается:

hashed_Password = sha1(s + password )
hashed_Password = sha1(password + s)

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

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

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

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

Данные из нашей взломанной базы данных:

RawPassword (not stored)  |  Hashed   |     Salt
--------------------------------------------------------
letmein                       WEFLS...       WEFOJFOFO...

Общий словарь паролей:

   Common Password
   --------------
   letmein
   12345
   ...

Для каждой пользовательской записи зациклируйте общие пароли и хешируйте их:

for each user in hacked_DB

    salt = users_salt
    hashed_pw = users_hashed_password

    for each common_password

        testhash = sha1(common_password + salt)
        if testhash = hashed_pw then
           //Match!  Users password = common_password
           //Lets visit the webpage and login now.
        end if

    next

next

Надеюсь, это иллюстрирует мою мысль намного лучше.

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

Обновление теории трещин

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

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

(((95 ^ 4)/2300000000)/2) * 10000 = 177 секунд

Учитывая полный диапазон из 95 печатных символов ASCII с максимальной длиной 4 символа, деленный на скорость вычисления (переменная), разделенный на 2 (при условии, что среднее время обнаружения пароля в среднем потребует 50% перестановок ) для 10 000 пользователей потребовалось бы 177 секунд, чтобы выработать все пароли пользователей, длина которых равна <= 4.

Скорее отрегулируйте его для реализма.

(((36 ^ 7)/1000000000)/2) * 10000 = 2 дня

Предполагая нечувствительность к регистру с длиной пароля <= 7, только буквенно-цифровыми символами, для 10 000 пользовательских записей потребуется 4 дня, и я сократил вдвое скорость алгоритма, чтобы отразить накладные и не идеальные обстоятельства.

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

Учитывая случай рекурсивного хэширования пароля 1000 раз, чтобы сделать эту задачу более дорогостоящей:

(((36 ^ 7)/1 000 000 000)/2) * 1000 секунды = 10,8839117 часов

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

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

Ответ 1

Да, вам нужно всего 3 дня для sha1 (salt | password). Вот почему хорошие алгоритмы хранения паролей используют хеширование 1000-итераций: вам понадобится 8 лет.

Ответ 2

Он не останавливает атаки на слова.

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

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

Обновление

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

Я знаю, что поддержка SHA-256 и SHA-512 была добавлена ​​в более новые версии криптографии GNU.

Ответ 3

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

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

Пример. С помощью 64-битной соли (т.е. 8 байт) вам нужно проверить дополнительные комбинации паролей 64 в атаке словаря. Со словарем, содержащим 200 000 слов, вам нужно будет сделать

200 000 * 2 64= 3.69 * 10 24

тесты в худшем случае - вместо 200 000 тестов без соли.

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

Обновление

Ваше обновление предполагает, что злоумышленник уже знает соль (или украл ее). Это, конечно, другая ситуация. Тем не менее злоумышленник не может использовать предварительно вычисленный радужный стол. Здесь важна скорость хеширования. Чтобы сделать атаку нецелесообразной, функция хеширования должна быть медленной. MD5 или SHA не являются хорошими кандидатами здесь, потому что они предназначены для быстрого, лучшими кандидатами для алгоритмов хэширования являются Blowfish или некоторые его варианты.

Обновление 2

Хорошо читайте о защите хэшей паролей в целом (гораздо больше, чем исходный вопрос, но все же интересно):

Достаточно с таблицами Rainbow: что вам нужно знать о схемах безопасного пароля

Следствие статьи: используйте соленые хэши, созданные с помощью bcrypt (на основе Blowfish) или Eksblowfish, который позволяет вам использовать настраиваемое время установки, чтобы замедлить хеширование.

Ответ 4

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

С солью пространство, необходимое для хранения словаря, быстро растет & hellip; так быстро, что попытка предварительно вычислить словарь пароля скоро станет бессмысленной.

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


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

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

Многие люди используют функцию PBKDF2, ключевую функцию деривации, которая подает результаты в хэш-функцию тысячи раз. Алгоритм "bcrypt" схож, используя медленный вывод итеративного ключа.

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


Комментарии

Ниже приведены комментарии, которые я сделал по этому вопросу.


Без солидатора злоумышленник не будет использовать метод, продемонстрированный в "Обновление 2". Он просто выполнил поиск в предварительно вычисленной таблице и получил пароль в O (1) или O (log n) time (n - количество потенциальных паролей). Соль - это то, что мешает этому, и заставляет его использовать подход O (n), показанный в "Обновление 2".

После сокращения до атаки O (n) мы должны учитывать, сколько времени занимает каждая попытка. Усиление ключа может привести к тому, что каждая попытка цикла займет полную секунду, а это означает, что время, необходимое для проверки паролей 10k на пользователях 10 тыс., Будет растягиваться от 3 дней до 3 лет & hellip; и только с паролями 10k вы, вероятно, взломаете нулевые пароли за это время.

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

Ключ-укрепление является частью стандартных алгоритмов деривации ключей PBKDF1 и PBKDF2, из PKCS # 5, которые делают отличные алгоритмы обфускации пароля ( "производный ключ" - это "хеш" ).

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


Конечно, вы предполагаете, что у нападающего есть все: соль, хеш, имя пользователя. Предположите, что злоумышленник является коррумпированным сотрудником хостинговой компании, который сбросил таблицу пользователей на фан-сайт myprettypony.com. Он пытается восстановить эти пароли, потому что он собирается развернуться и посмотреть, использовали ли ваши поклонники пони один и тот же пароль на своих учетных записях citibank.com.

С хорошо продуманной схемой паролей этот парень не сможет восстановить пароли.

Ответ 5

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

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

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

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

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

Ответ 6

Кроме того, еще одна важная точка - использование соли, используемой USER, предотвращает обнаружение двух пользователей с помощью SAME password - их хэши будут соответствовать. Вот почему много раз хэш-хэш (соль + имя пользователя + пароль)

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

Edit - только что заметил, что основное замечание было сделано в комментарии выше.

Ответ 7

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

Итак, скажем, мы работаем с SHA1, воспользовавшись недавними эксплойтами, обнаруженными с помощью этого алгоритма, и предположим, что у нас есть компьютер, работающий на 1,000,000 хэшей в секунду, для поиска столкновения потребуется 5,3 миллиона миллионов лет, так что php может работать 300 секунд, большой woop, на самом деле не имеет значения. Причина, по которой мы солидаем, состоит в том, что если кто-то потрудился генерировать все распространенные словарные фразы, (2 ^ 160 человек, добро пожаловать в эксплойты эпохи 2007 года).

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

RegistrationTime        UserName        UserPass    
1280185359.365591       briang      a50b63e927b3aebfc20cd783e0fc5321b0e5e8b5
1281546174.065087       test        5872548f2abfef8cb729cac14bc979462798d023

Фактически, схема соления - это ваш sha1 (время регистрации + имя пользователя). Давай, скажи мне мой пароль, это настоящие пароли в производстве. Вы даже можете сидеть и хешировать список слов в php. Удивительный.

Я не сумасшедший, я просто знаю, что это безопасно. Для удовольствия тестовый пароль test. sha1(sha1(1281546174.065087 + test) + test) = 5872548f2abfef8cb729cac14bc979462798d023

Вам нужно будет создать целую радужную таблицу, перпендикулярную 27662aee8eee1cb5ab4917b09bdba31d091ab732 только для этого пользователя. Это означает, что я могу позволить своим паролям не все скомпрометировать один стол радуги, хакеру нужно создать целый радужный стол для теста 27662aee8eee1cb5ab4917b09bdba31d091ab732 для тестирования, и снова f3f7735311217529f2e020468004a2aa5b3dee7f для briang. Вспомните 5,3 миллиона миллионов лет для всех хешей. Подумайте о размере хранения только хэшей 2 ^ 80 (что более 20 yottabytes), этого не произойдет.

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

Соль делает Rainbow table атакует гораздо сложнее, так как делает один хеш-пароль гораздо сложнее взломать. Представьте, что у вас есть ужасный пароль всего лишь 1. Атака радужного стола сразу же взломает.

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

Таким образом, если ваша соль является чем-то безопасным и случайным, скажите()% ISLDGHASKLU (% #% #, для таблицы хакеров радуги должна быть запись для 1 *()% ISLDGHASKLU (*% #% #. радужный стол на этом простом пароле уже не практичен.