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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

@onebyone.livejournal.com:

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

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

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

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

Ответ 7

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

Ответ 8

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