Солить ваш пароль: лучшие практики? - PullRequest
155 голосов
/ 23 марта 2009

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

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

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

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

Ответы [ 8 ]

105 голосов
/ 23 марта 2009

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

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

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

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

25 голосов
/ 23 марта 2009

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

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

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

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

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

18 голосов
/ 06 июля 2012

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

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

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

9 голосов
/ 23 марта 2009

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

7 голосов
/ 23 марта 2009

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

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

5 голосов
/ 24 марта 2009

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

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

@onebyone.livejournal.com:

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

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

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

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

4 голосов
/ 23 марта 2009

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

2 голосов
/ 23 марта 2009

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

...