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

Question

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

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

MySQL

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

Книга:

Инженерная криптография: принципы проектирования и практическое применение * Нильс Фергюсон, Брюс Шнайер и Тадаёси Коно

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

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

Answer 5

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

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

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

Answer 6

8 байтов достаточно.

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

$ id $ salt $ encrypted_password

• id определяет алгоритм хеширования

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

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