Солить свой пароль: передовой опыт?

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

Вы должны учитывать эти три вещи:

1. Соль должна быть разной для каждого пароля, который вы храните. (Это довольно распространенное заблуждение.)
2. Используйте криптографически безопасный генератор случайных чисел.
3. Выберите достаточно длинную соль. Подумайте о проблеме дня рождения.

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

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

Тот факт, что он есть, должен побеждать радужные таблицы.

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

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

Как я сказал. Это семантика. Выберите другую соль для пароля, длинную соль, и включите в нее нечетные символы, такие как символы и коды ASCII: © ¤¡

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

HMAC - лучший подход, но даже тогда, если вы используете что-то вроде SHA-1 , вы уже выбрали алгоритм, который не подходит для хеширования паролей из-за его скорости. Используйте что-то вроде bcrypt или, возможно, scrypt и полностью избавьтесь от проблемы.

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

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

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

Однако важно использовать длинные соли, генерировать их с помощью правильного криптографического ГПСЧ и иметь соли для каждого пользователя. Хранение солей для каждого пользователя в вашей базе данных не проблема безопасности, а использование хеша для всего сайта .

Прежде всего, термин «радужная таблица» постоянно используется неправильно. Радужная таблица - это просто особый вид таблицы поиска, который допускает определенный вид сжатия данных на ключах. При обмене вычислений на пространство справочная таблица, которая занимала бы 1000 ТБ, может быть сжата тысячу раз, чтобы ее можно было сохранить на меньшем диске.

Вам следует побеспокоиться о хеш-значениях таблиц поиска паролей, о радуге и т. Д.

@ onebyone.livejournal.com:

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

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

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

Более того, алгоритмы хеширования паролей, такие как PBKDF, составляют свою хэш-функцию несколько раз (рекомендуется повторять PBKDF-2 минимум 1000 раз, каждая итерация применяет SHA-1 дважды), что делает эту атаку вдвойне непрактичной.

BCrypt hash, если у платформы есть провайдер. Мне нравится, что вы не беспокоитесь о создании солей и можете сделать их еще сильнее, если хотите.

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