Неслучайная соль для хэшей паролей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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