Как использование соли делает пароль более безопасным, если он хранится в базе данных? - PullRequest
13 голосов
/ 24 октября 2010

В данный момент я изучаю Rails, но ответ не обязательно должен быть специфичным для Rails.

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

  • Пользователь создает пароль
  • Система шифрует пароль с помощью алгоритма шифрования (скажем, SHA2).
  • Хранить хэш зашифрованного пароля в базе данных.

При попытке входа в систему:

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

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

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

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

Однако эта соль хранится в столбце базы данных «соль».

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

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

Ответы [ 4 ]

8 голосов
/ 24 октября 2010

Прежде всего, то, что вы описали, это не атака радуги, это атака по словарю.

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

Чтобы иметь хоть какую-то надежду на эффективность, словарь должен включать что-то вроде миллиона входных данных (и миллион соответствующих результатов). Вы упомянули SHA-1, так что давайте использовать это для нашего примера. Он дает 20-байтовый (160-битный) результат. Давайте предположим, что средний ввод составляет около 8 символов. Это означает, что словарь должен быть примерно 28 мегабайт. Однако при использовании 32-битной соли размер и время создания словаря умножаются на 2 32 -1.

Так же, как в грубом приближении чрезвычайно , скажем, создание (несоленого) словаря заняло час. Чтобы сделать то же самое с 32-битной солью, потребуется 2 32 -1 часа, что составляет около 15 лет. Не так много людей, готовых потратить столько времени на атаку.

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

8 голосов
/ 24 октября 2010

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

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

2 голосов
/ 24 октября 2010

см. Принятый ответ на этот вопрос; Где вы храните соленые струны?

Это объясняет, как хэш препятствует атакам радуги.

1 голос
/ 24 октября 2010

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

...