Неслучайная соль для хэшей паролей - PullRequest
87 голосов
/ 11 февраля 2009

ОБНОВЛЕНИЕ: я недавно узнал от этого вопроса , что во всем последующем обсуждении я (и я уверен, что другие тоже) немного сбивает с толку: то, что я продолжаю называть радужным столом, на самом деле называется хэш-таблицей. Радужные столы являются более сложными существами и на самом деле являются разновидностью хэш-цепей Хеллмана. Хотя я полагаю, что ответ остается прежним (поскольку он не сводится к криптоанализу), некоторые обсуждения могут быть немного искажены.
Вопрос: « Что такое радужные столы и как они используются? »


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

Но действительно ли криптографически необходимо, чтобы соль была случайной? Будет ли в этом отношении какое-либо уникальное значение (уникальное для пользователя, например, userId)? Это фактически предотвратило бы использование единственной таблицы Rainbow для взлома всех (или большинства) паролей в системе ...
Но действительно ли недостаток энтропии ослабляет криптографическую силу хеш-функций?


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


Спасибо всем за ответы, но я хотел бы сосредоточиться на областях, с которыми я (немного) менее знаком. Главным образом последствия для криптоанализа - я был бы очень признателен, если бы кто-то имел какой-то вклад в криптоматематическое ПО.
Кроме того, если есть дополнительные векторы, которые не были учтены, это тоже хороший вход (см. Пункт @Dave Sherohman в нескольких системах).
Кроме того, если у вас есть какая-либо теория, идея или лучшая практика - пожалуйста, подкрепите это либо доказательствами, сценариями атак, либо эмпирическими данными. Или даже обоснованные соображения относительно приемлемых компромиссов ... Я знаком с передовой практикой (капитал B капитал P) по этому вопросу, я хотел бы доказать, какую ценность это на самом деле обеспечивает.


РЕДАКТИРОВАТЬ: Некоторые действительно хорошие ответы здесь, но я думаю, что, как говорит @Dave, все сводится к Rainbow Tables для общих имен пользователей ... и, возможно, менее распространенных имен. Тем не менее, что если мои имена пользователей являются глобально уникальными? Не обязательно уникален для моей системы, но для каждого пользователя - например, адрес электронной почты.
Не будет никакого стимула для создания RT для одного пользователя (как подчеркнул @Dave, соль не держится в секрете), и это все равно предотвратит кластеризацию. Единственная проблема заключается в том, что у меня может быть один и тот же адрес электронной почты и пароль на другом сайте, но соль все равно не помешает этому.
Итак, все сводится к криптоанализу - нужна энтропия или нет? (Мое нынешнее мышление не является необходимым с точки зрения криптоанализа, но это из других практических соображений.)

Ответы [ 9 ]

153 голосов
/ 11 февраля 2009

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

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

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

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

Отредактировано для добавления: Многие люди говорят об энтропии и важна ли энтропия в соли. Это так, но не по той причине, что большинство комментариев к нему, кажется, думают.

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

Причина, по которой энтропия важна, состоит в том, чтобы избежать кластеризации солевых значений. Если соль основана на имени пользователя, и вы знаете, что большинство систем будет иметь учетную запись с именем «root» или «admin», тогда вы можете создать радужную таблицу для этих двух солей, и она взломает большинство систем. Если, с другой стороны, используется случайная 16-битная соль и случайные значения имеют примерно равномерное распределение, то вам нужна радужная таблица для всех 2 ^ 16 возможных солей.

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

29 голосов
/ 11 февраля 2009

Использование соли с высокой энтропией абсолютно необходимо для безопасного хранения паролей.

Возьмите мое имя пользователя «gs» и добавьте его к моему паролю. «MyPassword» дает gsMyPassword. Это легко сломать, используя радужную таблицу, потому что, если у имени пользователя недостаточно энтропии, возможно, это значение уже сохранено в радужной таблице, особенно если имя пользователя короткое.

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

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

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

8 голосов
/ 26 октября 2010

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

хэш-функция ( "www.yourpage.com /" + имя пользователя + "/" + пароль)

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

7 голосов
/ 11 февраля 2009

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

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

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

3 голосов
/ 11 февраля 2009

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

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

3 голосов
/ 11 февраля 2009

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

Использование уникальных солей увеличивает сложность атаки по словарю BULK.

Было бы идеально иметь уникальное, криптографически сильное значение соли.

3 голосов
/ 11 февраля 2009

Сила хеш-функции не определяется ее вводом!

Использование соли, известной злоумышленнику, очевидно, делает создание радужной таблицы (особенно для жестко закодированных имен пользователей, таких как root ) более привлекательной, но не ослабляет хэш * 1006. *. Использование соли, неизвестной атакующему, сделает систему более трудной для атаки.

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

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

Однако я бы сказал, что ваш выбор алгоритма дайджеста важнее. Использование SHA-512 может оказаться более болезненным для человека, создающего радужный стол, чем, например, MD5.

1 голос
/ 11 февраля 2009

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

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

Чем меньше энтропии в соли, тем больше у вас шансов на генерирование того же значения соли, что и, следовательно, больше шансов на генерирование того же хеш-значения.

Природа хэш-значения является «постоянной», когда ввод известен, и «постоянной», что позволяет атакам по словарю или радужным таблицам быть настолько эффективными. Максимально варьируя полученное значение хеш-функции (используя высокие значения энтропийной соли), вы гарантируете, что хеширование одного и того же входного значения + случайной соли даст много разных результатов хеширования, что приведет к поражению (или, по крайней мере, значительному снижению эффективности) радуги атаки.

0 голосов
/ 11 февраля 2009

Энтропия - это точка солевого значения.

Если за солью есть какая-то простая и воспроизводимая «математика», то она такая же, как и соли. Просто добавление значения времени должно быть в порядке.

...