Соленое Поколение и программное обеспечение с открытым исходным кодом

Вы можете просто сгенерировать случайную соль для каждой записи во время выполнения. Например, предположим, что вы храните хешированные пароли пользователей в базе данных. Вы можете сгенерировать 8-символьную случайную строку, состоящую из строчных и прописных буквенно-цифровых символов во время выполнения, добавить ее к паролю, хэшу этой строке и сохранить ее в базе данных. Поскольку существует 62 ⁸ возможных солей, создание радужных таблиц (для каждой возможной соли) будет чрезмерно дорогостоящим; и поскольку вы используете уникальную соль для каждой записи пароля, даже если злоумышленник создал пару совпадающих радужных таблиц, он все равно не сможет взломать каждый пароль.

Вы можете изменить параметры генерации соли исходя из ваших потребностей в безопасности; например, вы можете использовать более длинную соль,

Используйте генератор случайных функций, чтобы сгенерировать соль и сохранить ее в базе данных, сделайте соль по одной на строку и сохраните ее в базе данных.

Мне нравится, как соль генерируется в django-registration. Ссылка: http://bitbucket.org/ubernostrum/django-registration/src/tip/registration/models.py#cl-85

salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
           activation_key=activation_key)

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

Сам Ша известен своей сильной и непоколебимой. Добавьте несколько измерений, чтобы сгенерировать саму соль, со случайным числом, sha и специфическим для пользователя компонентом, у вас непревзойденная безопасность!

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

Что такое соль?

Соль - это случайный набор байтов фиксированной длины, который добавляется к входным данным хеш-алгоритма.

Почему полезны сальцовка (или заполнение) хэша?

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

1. Использование соли значительно увеличивает сложность / стоимость предварительно вычисленных атак (включая радужные таблицы ).
2. Использование соли гарантирует, что один и тот же пароль не приведет к такой же хеш. Это гарантирует, что вы не сможете определить, имеют ли два пользователя одинаковый пароль. И, , что еще более важно , вы не можете определить, использует ли один и тот же человек один и тот же пароль в разных системах.
3. Использование соли увеличивает сложность паролей, тем самым значительно снижая эффективность обоих Dictionary- и Атаки на день рождения . (Это верно только в том случае, если соль хранится отдельно от хэша).
4. Правильное добавление соли значительно увеличивает потребность в хранилище для предвычислительных атак, вплоть до того, что они не выполняются. более практичный. (8-символьные чувствительные к регистру буквенно-цифровые пароли с 16-битной солью, хешированные до 128-битного значения, занимали бы чуть менее 200 эксабайт без уменьшения радуги).

Нет необходимости чтобы соль была в секрете.

Соль не является секретным ключом, вместо этого соль «работает», делая хэш-функцию специфичной для каждого экземпляра. При использовании соленого хеша существует не одна хеш-функция, а одна для всех возможных значений соли. Это предохраняет злоумышленника от атаки N хешированных паролей за сумму, меньшую, чем в N раз больше стоимости атаки одного пароля. В этом суть проблемы.
«Секретная соль» - это не соль, она называется «ключом» и означает, что вы больше не вычисляете хеш, а Код аутентификации сообщения (MAC). Вычисление MAC - дело непростое (гораздо сложнее, чем просто объединить ключ и значение в хеш-функцию), и это совсем другая тема.

Соль должна быть случайной для каждого случая, когда Это использовано. Это гарантирует, что злоумышленник должен атаковать каждый соленый хэш отдельно.
Если вы полагаетесь на секретность своей соли (или алгоритма соления), вы попадаете в области Security Through Obscurity (не сработает). Скорее всего, вы не получите дополнительной защиты от соляной тайны; вы просто испытываете теплое нечеткое чувство безопасности. Так что вместо того, чтобы сделать вашу систему более безопасной, она просто отвлекает вас от реальности.

Итак, почему соль должна быть случайной?

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

Заманчиво попытаться получить соль из некоторых данных, которые "предположительно уникальны", таких как идентификатор пользователя, но такие схемы часто терпят неудачу из-за некоторых неприятных деталей:

1. Если вы используете , например, идентификатор пользователя , некоторые злоумышленники, атакующие отдельные системы, могут просто объединить свои ресурсы и создать предварительно вычисленные таблицы для идентификаторов пользователей с 1 по 50. Идентификатор пользователя является уникальным в масштабе всей системы , но не во всем мире .

2. То же самое относится к имени пользователя : для каждой системы Unix существует один "root" система, но в мире много корней. Радужная таблица для «root» стоила бы усилий, поскольку ее можно было бы применить к миллионам систем. Еще хуже, есть также много «бобов», и многие из них не прошли обучение системному администратору: их пароли могут быть довольно слабыми.

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

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

В заключение:

Используйте случайную, равномерно распределенную соль с высокой энтропией. Используйте новую соль всякий раз, когда вы создаете новый пароль или меняете пароль. Сохраните соль вместе с хешированным паролем. Отдавайте предпочтение большим значениям соли (не менее 10 байт, предпочтительно 16 или более).

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

Полезные источники:
stackoverflow.com: Неслучайная соль для пароля хеши
Брюс Шнайер: Практическая криптография (книга)
Безопасность Matasano: Достаточно радужных таблиц
usenix.org: В крипте Unix использовалась соль с 1976 года
owasp.org : Зачем добавляют соль
openwall.com : Salts

Заявление об ограничении ответственности:
Я не эксперт по безопасности. (Хотя этот ответ был рассмотрен Томасом Порнином )
Если кто-то из специалистов по безопасности обнаружит что-то не так, прокомментируйте или отредактируйте этот ответ вики.

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

Это имеет хорошие эффекты. Во-первых, злоумышленники не могут просто составить список ожидаемых паролей, таких как «Пароль1», хэшировать их в радужную таблицу и просмотреть ваш файл паролей в поисках совпадений. Если у вас есть хорошая двухбайтовая соль, они должны генерировать 65 536 значений для каждого ожидаемого пароля, и это делает радужную таблицу намного менее практичной. Во-вторых, если вам удастся скрыть от злоумышленников, просматривающих ваш файл паролей, вычисление возможных значений будет намного сложнее. В-третьих, вы мы сделали невозможным для злоумышленников определить, использует ли данный человек один и тот же пароль на разных сайтах.

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

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

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