Salt Generation и программное обеспечение с открытым исходным кодом

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

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

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

Мысли?

70 голосов | спросил user199085 29 +03002009-10-29T20:00:59+03:00312009bEurope/MoscowThu, 29 Oct 2009 20:00:59 +0300 2009, 20:00:59

6 ответов


0

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

ответил kemiller2002 29 +03002009-10-29T20:03:55+03:00312009bEurope/MoscowThu, 29 Oct 2009 20:03:55 +0300 2009, 20:03:55
0

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


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

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


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

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

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


Не нужно, чтобы соль была секретной.

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

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


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

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

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

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

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

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

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


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

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

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


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

Отказ от ответственности:
Я не эксперт по безопасности. (Хотя этот ответ был рассмотрен Томасом Порниным )

Если кто-то из специалистов по безопасности найдет что-то не так, пожалуйста, прокомментируйте или отредактируйте этот вики-ответ.

ответил kemiller2002 29 +03002009-10-29T20:03:55+03:00312009bEurope/MoscowThu, 29 Oct 2009 20:03:55 +0300 2009, 20:03:55
0

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

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

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

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

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

ответил David Thornley 30 +03002009-10-30T18:34:29+03:00312009bEurope/MoscowFri, 30 Oct 2009 18:34:29 +0300 2009, 18:34:29
0

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

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

ответил mipadi 29 +03002009-10-29T20:10:12+03:00312009bEurope/MoscowThu, 29 Oct 2009 20:10:12 +0300 2009, 20:10:12
0

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

Мне нравится, как соль генерируется в django-регистрации. Ссылка: http://bitbucket.org/ubernostrum /Джанго-регистрация /SRC /наконечник /регистрация /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 хорошо известен как сильный и нерушимый. Добавьте несколько измерений, чтобы создать саму соль, со случайным числом, sha и пользовательским компонентом, у вас есть нерушимая безопасность!

ответил Lakshman Prasad 29 +03002009-10-29T20:13:36+03:00312009bEurope/MoscowThu, 29 Oct 2009 20:13:36 +0300 2009, 20:13:36
0

В случае настольного приложения, которое шифрует данные и отправляет их на удаленный сервер, как вы считаете, каждый раз использовать разные соли?

Используя PKCS # 5 с паролем пользователя, ему требуется соль для генерации ключа шифрования, для шифрования данных. Я знаю, что хранить жестко закодированную соль в настольном приложении не очень хорошая идея.

Если удаленный сервер НИКОГДА не должен знать пароль пользователя, можно ли каждый раз использовать разные соли? Если пользователь использует настольное приложение на другом компьютере, как он сможет расшифровать данные на удаленном сервере, если у него нет ключа (он не задан жестко в программном обеспечении)?

ответил Normand Bedard 26 Maypm11 2011, 19:48:10

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132