Почему соли делают словарные атаки «невозможными»? - PullRequest
85 голосов
/ 25 августа 2010

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

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

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. </p>

Давайте немного подстроим для реалистичности.

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

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

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

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

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

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

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

Ответы [ 11 ]

1 голос
/ 25 августа 2010

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

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

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

...