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

Я разрабатываю систему аутентификации, которая работает следующим образом:

Пользователь вводит пароль
Соль генерируется.
Пароль хэшируется с помощью вихревой сети
Whirlpool hashed пароль, конкатенированный с простой солью.
Конкатенированная версия хешируется с помощью sha1 и сохраняется в базе данных.
Я правильно проверяю пароль, хешируя пароль на прикладном уровне, а затем делаю это (в MySQL):

MySQL

WHERE `Password` = SHA1(CONCAT('$hashedPassword',`Salt`)) AND [..]

В настоящий момент моя соль составляет 64 байта. Будет ли этого достаточно, чтобы сделать его невозможным для атаки словаря?

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

Ответ 1

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

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

Учитывая типичный размер такого радужного стола, крайне маловероятно, что кто-то уже предварительно вычислил такие таблицы для солей даже небольшого размера, например, 8 байтов (рассмотрим количество возможных солей: 256^8 = 18446744073709551616). Предпосылка, конечно, состоит в том, что соли генерируются случайным образом и что вы не используете одно и то же значение соли несколько раз. 64 байта не могут повредить, конечно, нет ничего плохого в этом.

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

Ответ 2

Моя копия Практическая криптография (Ferguson, Schneier) с датой авторских прав 2003 года предлагает использовать 256 бит (32 байта) для длины соли. В нем говорится, что 128 бит "вероятно" в порядке, но, как он указывает, биты дешевы. Учитывая, что относительно минимальная стоимость хранения 64 байтов для соли на диске для каждого пароля представляется разумной. Это, вероятно, слишком много, но это не повредит.

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

Ответ 3

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

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

Каждый бит соли удваивает пространство, необходимое для таблицы поиска. Таким образом, 8 байтов (64 бита) приведут к пространственному умножителю в 16 миллионов терабайт, полностью занимая пространство в диапазоне yottabyte (и, вероятно, вне досягаемости большинства злоумышленников).

Ответ 4

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

В настоящее время PKCS # 5 рекомендует иметь длину соли не менее 64 бит энтропии, часто рекомендуется bcrypt использует 128 бит, и вы даже можете использовать больше. Но определенно есть точка, в которой вы не добавите дополнительной практической сложности, поскольку возникающая в результате сложность уже утопична.

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

Ответ 5

Книга:

Криптографическое проектирование: принципы проектирования и практические применения

Нильса Фергюсона, Брюса Шнайера и Тадаёши Коно

21.2.1 Соление и растяжка

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

Ответ 6

8 байтов являются достаточными.

Когда вы смотрите в Linux (версия ядра 3.16) в /etc/shadow, где сохраняются пароли пользователя, вы можете увидеть такую форму:

$ID $соль $encrypted_password

id определяет хэш-алгоритм

В моей Linux-версии соль составляет 8 цифр, поэтому 8 байтов, и я думаю, что разработчики ядра знают, что они делают, поэтому я также использую 8 байтов для моей соли, которые исходят из источника криптографически безопасного псевдослучайного генератора. В Linux вы можете просто читать /dev/random (который блокируется при низкой энтропии) или /dev/urandom (который не блокируется).

Для получения дополнительной информации прочтите manpages для crypt.