Подтвердить что ты не робот

Как использование соли делает пароль более безопасным, если он хранится в базе данных?

Я изучаю Rails на данный момент, но ответ не обязательно должен быть Rails.

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

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

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

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

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

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

Ответ 4

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