Солить ваш пароль: лучшие практики?

Мне всегда было любопытно ... Что лучше при добавлении пароля для хеширования: префикс или постфикс? Зачем? Или это имеет значение, пока ты солишь?

Объяснение: мы все (будем надеяться) уже знаем, что мы должны запечатать пароль перед тем, как хешировать его для хранения в базе данных [ Редактировать: чтобы вы могли избежать таких вещей, как то, что недавно произошло с Джеффом Этвудом ]. Обычно это делается путем объединения соли с паролем перед передачей его через алгоритм хеширования. Но примеры различны ... Некоторые примеры ставят соль перед паролем. Некоторые примеры добавляют соль после пароля. Я даже видел некоторых, которые пытаются положить соль в середину.

Так какой метод лучше и почему? Есть ли метод, который уменьшает вероятность столкновения хеша? Мой Google не нашел достойного анализа по этому вопросу.

Изменить: Великие ответы, ребята! Извините, я мог выбрать только один ответ. :)

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

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

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

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

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

Факт, что это там, должен победить радужные столы.

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

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

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

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

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

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

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

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

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

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

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

@ Onebyone.livejournal.com:

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

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

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

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

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

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