Совершенно очевидно, что любая соль вообще поможет при создании и хешировании пароля пользователя. Есть ли какие-нибудь рекомендации относительно того, как долго должна быть соль? Я буду хранить соль в своей пользовательской таблице, поэтому мне нужен лучший компромисс между размером хранилища и безопасностью. Достаточно ли случайной соли из 10 символов? Или мне нужно что-то более длинное?
Какова оптимальная длина соли пароля пользователя?
08.10.2008
- У меня нет рекомендаций по длине соли, но ответы, которые здесь появляются, содержат много неверной информации. Ваша соль определенно должна: - быть случайной - быть за секрет (ни одно значение, хранящееся в образе вашей программы или файле конфигурации). Соль не является криптографическим секретом, поэтому хранить ее в таблице не проблема. Единственная цель соли - гарантировать, что при хешировании (или шифровании) разных экземпляров одного и того же элемента вы получите другой результат. 08.10.2008
- Для тех, кто не знает, что такое соль: ‹a href=en.wikipedia. org / wiki / Salt_ (криптография) ›Salt (криптография) ‹/a› в Википедии 08.10.2008
- Или есть оптимальное соотношение длины соли к длине хеш-вывода? 8-байтовой соли может быть достаточно для HMAC-SHA-256, но может не хватить для HMAC-SHA-512. 23.02.2011
- Криптографически случайная соль того же размера, что и результат хэш-функции, означает, что попытка атаки с использованием всех возможных солей (плюс словарь паролей) требует таких же усилий, как попытка атаки с использованием всех возможных результатов хеширования, что является стандартной грубой силой. Более короткая соль означает, что у вас может быть словарь соли плюс словарь паролей в качестве атаки методом грубой силы. 07.07.2011
- -1 По общему признанию, не отвечает (даже не пытается) ответить на вопрос. 31.08.2011
Ответы:
1
Большинство этих ответов немного ошибочны и демонстрируют путаницу между солями и криптографическими ключами. Целью включения солей является изменение функции, используемой для хеширования пароля каждого пользователя, так что каждый сохраненный хэш пароля нужно будет атаковать индивидуально. Единственное требование безопасности - они должны быть уникальными для каждого пользователя, и нет никакой пользы в том, что они непредсказуемы или их трудно угадать.
Соли должны быть достаточно длинными, чтобы соль каждого пользователя была уникальной. Случайные 64-битные соли вряд ли когда-либо повторится даже с миллиардом зарегистрированных пользователей, так что это должно быть нормально. Однократное повторение соли является относительно незначительной проблемой безопасности, она позволяет злоумышленнику искать сразу в двух учетных записях, но в совокупности не сильно ускоряет поиск по всей базе данных. Даже 32-битные соли подходят для большинства целей, в худшем случае это ускорит поиск злоумышленника примерно на 58%. Стоимость увеличения солей сверх 64 бит невелика, но для этого нет никаких причин с точки зрения безопасности.
Есть некоторые преимущества в использовании соли для всего сайта поверх соли для каждого пользователя, это предотвратит возможные конфликты с хешами паролей, хранящимися на других сайтах, и предотвратит использование общих радужных таблиц, хотя даже 32 бита соли достаточно, чтобы сделать радужные столы непрактичной атакой.
Еще проще - и разработчики всегда игнорируют это - если у вас есть уникальные идентификаторы пользователей или имена для входа, они отлично подходят в качестве соли. Если вы это сделаете, вам следует добавить соль для всего сайта, чтобы избежать дублирования с пользователями другой системы, у которых была такая же блестящая идея.
04.03.2011
2
В настоящее время принятые стандарты хеширования паролей создают новую соль длиной 16 символов для каждый пароль и сохраните соль с хешем пароля.
Конечно, для создания действительно случайной соли необходимо принять надлежащие криптографические меры.
08.10.2008
3
Изменить: мой ответ ниже отвечает на заданный вопрос, но «настоящий» ответ таков: просто используйте bcrypt, scrypt или Argon2. Если вы задаете подобные вопросы, вы почти наверняка используете инструменты слишком низкого уровня.
Честно говоря, нет никаких веских причин, чтобы длина соли не была такой же, как у хешированного пароля. Если вы используете SHA-256, у вас есть 256-битный хеш. Нет причин не использовать 256-битную соль.
Более 256 бит не принесут вам никакого улучшения безопасности с математической точки зрения. Но использование более короткой соли всегда может привести к ситуации, когда радужный стол будет соответствовать длине соли, особенно с более короткими солями.
08.09.2009
4
Методы SHA2-crypt и bcrypt, используемые в Linux, BSD Unix и Solaris, имеют длину 128 бит. Эти большие значения соли делают предвычислительные атаки с паролем практически любой длины для этих систем в обозримом будущем невозможными.
128-битной (16-байтовой) соли будет достаточно. Вы можете представить его как последовательность 128 / 4 = 32 шестнадцатеричных цифр.
12.03.2012
5
Один из ответов может заключаться в том, чтобы использовать в качестве размера соли значение, которое хэш, который вы собираетесь использовать, обеспечивает с точки зрения безопасности.
Например. Если вы собираетесь использовать SHA-512, используйте 256-битную соль, поскольку безопасность, обеспечиваемая SHA-512, составляет 256 бит.
13.01.2015
Новые материалы
Аргументы прогрессивного улучшения почти всегда упускают суть
В наши дни в кругах веб-разработчиков много болтают о Progressive Enhancement — PE, но на самом деле почти все аргументы с обеих сторон упускают самую фундаментальную причину, по которой PE..
Введение в Джанго Фреймворк
Схема «работать умно, а не усердно»
В этой и последующих статьях я познакомлю вас с тем, что такое фреймворк Django и как создать свое первое приложение с помощью простых и понятных шагов, а..
Настольный ПК как «одно кольцо, чтобы править всеми» домашних компьютеров
Вид после 9 месяцев использования
С настольных компьютеров все началось, но в какой-то момент они стали «серверами», и мы все перешли на ноутбуки. В прошлом году я столкнулся с идеей настольных..
Расширенные методы безопасности для VueJS: реализация аутентификации без пароля
Руководство, которое поможет вам создавать безопасные приложения в долгосрочной перспективе
Безопасность приложений часто упускается из виду в процессе разработки, потому что основная..
стройный-i18следующий
Представляем стройную оболочку для i18next.
Эта библиотека, основанная на i18next, заключает экземпляр i18next в хранилище svelte и отслеживает события i18next, такие как languageChanged,..
Обзор 20 основных и современных методов работы с массивами в JavaScript
Вы знаете их всех?
В этом коротком посте я покажу сводку методов, доступных в JavaScript для работы с массивами. Я надеюсь, что вы найдете это полезным!
В конце поста вы найдете ссылку на..
Да, но я чувствую необходимость указать, что это или не единственные два.
Да, но я чувствую необходимость указать, что это или не единственные два. Обучение с подкреплением (в качестве примера) также является важным.