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

129

Любая соль явно поможет при солении и хешировании пароля пользователя. Есть ли какие-нибудь рекомендации относительно того, как долго должна быть соль? Я буду хранить соль в своей таблице пользователей, поэтому мне нужен лучший компромисс между размером хранилища и безопасностью. Достаточно ли случайной соли из 10 символов? Или мне нужно что-то более длинное?

encryption hash salt Дэвид
источник
10
У меня нет рекомендаций относительно длины соли, но ответы, которые здесь появляются, содержат много неверной информации. Ваша соль определенно должна: - быть случайной - быть за секрет (ни одно значение, хранящееся в вашем образе программы или файле конфигурации). Соль не является криптографическим секретом, поэтому хранить ее в таблице не проблема. Единственная цель соли - гарантировать, что при хешировании (или шифровании) разных экземпляров одного и того же элемента вы получите другой результат.
Майкл Берр
2
Для тех, кто не знает, что такое соль: <a href=" en.wikipedia.org/wiki/Salt_(cryptography)"> Соль (криптография) </a> в Википедии
Дэвид Келле,
1
Или есть оптимальное соотношение длины соли к длине хеш-вывода? 8-байтовой соли может быть достаточно для HMAC-SHA-256, но не для HMAC-SHA-512.
Crend King
1
Криптографически случайная соль того же размера, что и результат хэш-функции, означает, что атака «испробовать все возможные соли» (плюс словарь паролей) требует таких же усилий, как атака «испробовать все возможные результаты хеширования», которая является стандартной грубой силой. , Более короткая соль означает, что у вас может быть словарь соли плюс словарь паролей в качестве атаки методом грубой силы.
Ричард Гадсден
-1 Правда, не отвечает (даже не пытается) ответить на вопрос.
user359996

Ответы:

71

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

Соли должны быть достаточно длинными, чтобы соль каждого пользователя была уникальной. Случайные 64-битные соли вряд ли когда-либо повторится даже с миллиардом зарегистрированных пользователей, так что это должно быть нормально. Однократное повторение соли является относительно незначительной проблемой безопасности, она позволяет злоумышленнику искать сразу в двух учетных записях, но в совокупности не сильно ускоряет поиск по всей базе данных. Даже 32-битные соли подходят для большинства целей, в худшем случае это ускорит поиск злоумышленника примерно на 58%. Стоимость увеличения солей сверх 64 бит невелика, но для этого нет никаких оснований безопасности.

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

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

SecurityJoe
источник
16
В том, что соли непредсказуемы, есть преимущество. Предсказуемая соль может быть предсказана и использована в атаке по хеш-таблице. Например, если ваша соль - это просто идентификатор пользователя, тогда простая альфа-хэш-таблица, достаточно длинная, будет включать не только все пароли, но и все комбинации имени пользователя и пароля.
Ричард Гадсден
7
Обратите внимание, что в отношении вашего последнего абзаца, если вы используете соль для всего сайта, это должно быть именно так: для всего сайта. Не для всего приложения, то есть каждый новый экземпляр, который вы устанавливаете, должен создавать новую соль для всего сайта. Например, если бы Windows использовала одну и ту же соль для каждой базы данных аутентификации Windows, тогда было бы целесообразно создать радужную таблицу для этой соли, но если бы каждая установка Windows генерировала новую соль, тогда этого не было бы.
Ричард Гадсден
5
Проблема на самом деле не в том, что соль нужно сложно угадывать. Злоумышленнику не нужно угадывать соль: у любого, кто имеет доступ к хешу, уже есть соль. Проблема в том, что если ваши соли очень распространены (например, имена пользователей), они могут быть такими же, как и на других сайтах, и в этот момент злоумышленнику потребуется гораздо меньший набор радужных таблиц, чтобы сделать атаки возможными. Вот почему упоминается идея соли для каждого сайта, чтобы избежать такого рода конфликтов с другими сайтами.
Nate CK
3
Краткое примечание: если в качестве соли используются имена пользователей, это может стать проблемой при изменении имен пользователей. На практике (несмотря на то, что сказано в проектной документации заказчика) я обнаружил, что пользователи часто хотят изменить имена пользователей.
SilentSteel
6
@ NateC-K, Идея поваренной соли, о которой вы говорите, называется перцем.
Pacerier
35

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

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

Дэвид Шмитт
источник
6
Характер немного некорректен. Вы должны сказать байт .
CodesInChaos 08
10
@CodesInChaos, я думаю, вы имеете в виду октет ;-)
user2864740 05
1
Здравствуй! Похоже, что статья в Википедии изменена - может, вам стоит обратиться к en.wikipedia.org/wiki/PBKDF2 или что-то в этом роде?
Борис Треухов
5
Или еще лучше owasp.org/index.php/Password_Storage_Cheat_Sheet
Борис Треухов
25

Изменить: мой ответ ниже отвечает на заданный вопрос, но «настоящий» ответ: просто используйте bcrypt , scrypt или Argon2 . Если вы задаете подобные вопросы, вы почти наверняка используете инструменты слишком низкого уровня.

Честно говоря, нет никаких веских причин, чтобы длина соли не была такой же, как у хешированного пароля. Если вы используете SHA-256, у вас есть 256-битный хеш. Нет причин не использовать 256-битную соль.

Более 256 бит не принесут вам никакого улучшения безопасности математически. Но использование более короткой соли всегда может привести к ситуации, когда радужный стол догонит вашу длину соли - особенно с более короткими солями.

Стивен Тоусе
источник
11
Это не что большая сделка; пользователь едва ли заметит разницу между миллисекундным хешем и полсекундным хешем, плюс хеширование пароля на самом деле должно занимать больше времени, чтобы замедлить атаки методом грубой силы - хотя типичные три удара, заблокированные на 15 минут, лучше. Вы тратите на это циклы ЦП? Да что угодно. В любом случае ЦП тратит больше времени в режиме ожидания, чем на большинстве веб-сайтов, так какое это имеет значение? Если вы столкнулись с проблемами производительности, выполните горизонтальное масштабирование.
Randolpho
14
Соли защищают от радужных столов. 512-битная соль с 256-битным хешем все равно приведет только к 256 битам энтропии в окончательном пароле.
Стивен Тусет,
8
Медленное хеширование - это особенность, а не ошибка.
outis
7
Если у вас есть 3-битный хеш, ваша 9999-битная соль по-прежнему будет хешировать только до 3 возможных бит энтропии. Радужная таблица должна будет найти только три соли для каждого пароля, которые приведут к другому результату, который является постоянным мультипликативным множителем и, таким образом, отброшен из большого О.
Stephen Touset 06
2
.................................................. .................................... особая система. Цель солей , чтобы остановить Предвычисления атаки , так что хэши не могут быть найдены и немедленно отменено в незашифрованном виде . С 9999-битной солью ваш пароль остается секретом , тогда как с 3-битной солью ваш пароль теперь известен всему миру (и они могут использовать его для входа в другие ваши учетные записи, поскольку многие люди часто используют пароли повторно). Мне кажется забавным, что 5 человек здесь на самом деле проголосовали за ваш комментарий из-за слова «энтропия» в нем.
Pacerier
7

Википедия :

Методы SHA2-crypt и bcrypt, используемые в Linux, BSD Unix и Solaris, имеют длину 128 бит. Эти большие значения соли делают предвычислительные атаки с паролем практически любой длины на эти системы в обозримом будущем невозможными.

128-битной (16-битной) соли будет достаточно. Вы можете представить его как последовательность 128 / 4 = 32шестнадцатеричных цифр.

Андрей Немченко
источник
Мне кажется, что пример того, что используют другие безопасные системы, является отличным примером того, что является передовой практикой.
cjbarth 01
1
@ mklement0 Спасибо, обновил ответ.
Андрей Немченко
2

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

Например, если вы собираетесь использовать SHA-512, используйте 256-битную соль, поскольку безопасность, обеспечиваемая SHA-512, составляет 256 бит.

Роберто Мартеллони
источник