Неслучайная соль для хэшей паролей
ОБНОВЛЕНИЕ: я недавно узнал из этого вопроса, что во всем обсуждении ниже я (и я уверен, что другие тоже) немного сбивает с толку: то, что я продолжаю называть радужным столом, на самом деле называется хеш-таблицей. Радужные столы являются более сложными существами и на самом деле являются разновидностью хэш-цепей Хеллмана. Хотя я полагаю, что ответ остается прежним (поскольку он не сводится к криптоанализу), некоторые обсуждения могут быть немного искажены.
Вопрос: " Что такое радужные столы и как они используются?"
Как правило, я всегда рекомендую использовать криптографически сильное случайное значение в качестве соли для использования с хэш-функциями (например, для паролей), например, для защиты от атак Rainbow Table.
Но действительно ли криптографически необходимо, чтобы соль была случайной? Достаточно ли в этом отношении какого-либо уникального значения (уникального для пользователя, например, userId)? Это фактически предотвратило бы использование одной таблицы Rainbow для взлома всех (или большинства) паролей в системе...
Но действительно ли отсутствие энтропии ослабляет криптографическую силу хеш-функций?
Обратите внимание, я не спрашиваю о том, почему использовать соль, как ее защитить (это не нужно), использовать один постоянный хэш (не надо) или какую хеш-функцию использовать.
Нужна ли соль энтропии или нет.
Спасибо всем за ответы, но я хотел бы сосредоточиться на областях, с которыми я (немного) менее знаком. Главным образом последствия для криптоанализа - я был бы признателен, если кто-то имеет какой-либо вклад от криптоматематического PoV.
Кроме того, если есть дополнительные векторы, которые не были учтены, это тоже хороший вклад (см. Пункт @Dave Sherohman в нескольких системах).
Кроме того, если у вас есть какая-либо теория, идея или лучшая практика - пожалуйста, подкрепите это либо доказательствами, сценариями атак, либо эмпирическими данными. Или даже обоснованные соображения относительно приемлемых компромиссов... Я знаком с Лучшей практикой (капитал B капитал P) по этому вопросу, я хотел бы доказать, какую ценность это на самом деле обеспечивает.
РЕДАКТИРОВАТЬ: Некоторые действительно хорошие ответы здесь, но я думаю, что, как говорит @Dave, все сводится к Rainbow Tables для общих имен пользователей... и, возможно, менее распространенных имен. Тем не менее, что, если мои имена пользователей являются глобально уникальными? Не обязательно уникален для моей системы, но для каждого пользователя - например, адрес электронной почты.
Не будет никакого стимула для создания RT для одного пользователя (как подчеркнул @Dave, соль не держится в секрете), и это все равно предотвратит кластеризацию. Единственная проблема заключается в том, что у меня может быть один и тот же адрес электронной почты и пароль на другом сайте, но соль все равно не помешает.
Итак, все сводится к криптоанализу - нужна энтропия или нет? (Мое нынешнее мышление не является необходимым с точки зрения криптоанализа, но это из других практических соображений.)
9 ответов
Соль традиционно хранится в виде префикса к хешированному паролю. Это уже дает знать любому злоумышленнику, имеющему доступ к хешу пароля. Использование имени пользователя в качестве соли или нет не влияет на эти знания и, следовательно, не влияет на безопасность одной системы.
Однако использование имени пользователя или любого другого контролируемого пользователем значения в качестве соли уменьшит межсистемную безопасность, поскольку пользователь, имеющий одинаковые имя пользователя и пароль в нескольких системах, использующих один и тот же алгоритм хеширования паролей, в конечном итоге получит один и тот же хэш паролей. каждая из этих систем. Я не считаю это серьезной ответственностью, поскольку я, как злоумышленник, вначале пробовал бы использовать пароли, которые, как известно, целевая учетная запись использовала в других системах, прежде чем пытаться использовать любые другие способы взлома учетной записи. Одинаковые хеши только сообщают мне заранее, что известный пароль будет работать, они не облегчат реальную атаку. (Тем не менее, обратите внимание, что быстрое сравнение баз данных учетных записей предоставит список целей с более высоким приоритетом, так как он скажет мне, кто есть, а кто не использует пароли повторно.)
Большая опасность этой идеи заключается в том, что имена пользователей обычно используются повторно - практически на любом сайте, который вы хотите посетить, будет, например, учетная запись пользователя с именем "Dave", а "admin" или "root" встречаются еще чаще, что построение радужных таблиц, ориентированных на пользователей с этими общими именами, намного проще и эффективнее.
Оба этих недостатка могут быть эффективно устранены путем добавления второго значения соли (фиксированного и скрытого или открытого как стандартная соль) к паролю перед его хэшированием, но в этот момент вы все равно можете просто использовать стандартную энтропийную соль вместо этого работы с именем пользователя в него.
Отредактировано, чтобы добавить: много людей говорят об энтропии и важна ли энтропия в соли. Это так, но не по той причине, что большинство комментариев к нему, кажется, думают.
Общая мысль, кажется, заключается в том, что энтропия важна, так что злоумышленнику будет трудно угадать соль. Это неверно и, по сути, совершенно не имеет значения. Как уже несколько раз указывали разные люди, атаки, на которые будет влиять соль, могут совершать только те, у кого есть база данных паролей, а кто-то с базой данных паролей может просто посмотреть, что является солью каждой учетной записи. Будь это угадано или нет, не имеет значения, когда вы можете просто найти его.
Причина, по которой энтропия важна, состоит в том, чтобы избежать кластеризации соленых ценностей. Если соль основана на имени пользователя, и вы знаете, что у большинства систем будет учетная запись с именем "root" или "admin", тогда вы можете создать радужную таблицу для этих двух солей, и она взломает большинство систем. Если, с другой стороны, используется случайная 16-битная соль и случайные значения имеют примерно равномерное распределение, то вам нужна радужная таблица для всех 2^16 возможных солей.
Речь идет не о том, чтобы помешать злоумышленнику узнать, что такое соль индивидуального аккаунта, а не о том, чтобы дать им большую, жирную цель одной соли, которая будет использоваться для значительной части потенциальных целей.
Использование соли с высокой энтропией абсолютно необходимо для безопасного хранения паролей.
Возьмите мое имя пользователя "gs" и добавьте его к моему паролю. "MyPassword" дает gsMyPassword. Это легко сломать, используя радужную таблицу, потому что, если у имени пользователя недостаточно энтропии, возможно, это значение уже сохранено в радужной таблице, особенно если имя пользователя короткое.
Другой проблемой являются атаки, когда вы знаете, что пользователь участвует в двух или более сервисах. Существует много общих имен пользователей, вероятно, наиболее важными из них являются admin и root. Если кто-то создал радужную таблицу, в которой есть соли с наиболее распространенными именами пользователей, он может использовать их для взлома учетных записей.
Раньше у них была 12-битная соль. 12 бит - это 4096 разных комбинаций. Это было недостаточно безопасно, потому что в настоящее время можно легко хранить такую информацию. То же самое относится к 4096 наиболее часто используемым именам пользователей. Вполне вероятно, что некоторые из ваших пользователей будут выбирать имя пользователя, которое относится к наиболее распространенным именам пользователей.
Я нашел эту проверку пароля, которая определяет энтропию вашего пароля. Наличие меньшей энтропии в паролях (например, при использовании имен пользователей) значительно облегчает работу радужных таблиц, поскольку они пытаются покрыть по крайней мере все пароли с низкой энтропией, поскольку они более вероятны.
Это правда, что само имя пользователя может быть проблематичным, так как люди могут делиться именами пользователей на разных сайтах. Но это должно быть довольно проблематичным, если пользователи имеют разные имена на каждом сайте. Так почему бы не сделать его уникальным на каждом сайте. Взломать пароль примерно так
хэш-функцию ("www.yourpage.com/"+ имя пользователя +"/"+ пароль)
Это должно решить проблему. Я не мастер криптоанализа, но я уверен, что тот факт, что мы не используем высокую энтропию, сделает хэш слабее.
Мне нравится использовать и то и другое: соль с высокой энтропией для каждой записи плюс уникальный идентификатор самой записи.
Хотя это не сильно повышает безопасность от атак по словарю и т. Д., Это действительно исключает случай, когда кто-то копирует свою соль и хэш в другую запись с намерением заменить пароль своим собственным.
(Правда, трудно придумать обстоятельства, в которых это применимо, но я не вижу вреда в поясах и скобах, когда речь идет о безопасности.)
Если соль известна или легко угадывается, вы не увеличили сложность атаки по словарю. Возможно даже создать модифицированный радужный стол, который учитывает "постоянную" соль.
Использование уникальных солей увеличивает сложность BULK словарных атак.
Иметь уникальную криптографически сильную солевую ценность было бы идеально.
Сила хеш-функции не определяется ее входом!
Использование соли, известной злоумышленнику, очевидно, делает создание радужной таблицы (особенно для жестко закодированных имен пользователей, таких как root) более привлекательным, но не ослабляет хэш. Использование соли, которая неизвестна атакующему, усложнит атаку системы.
Объединение имени пользователя и пароля может по-прежнему обеспечивать запись для интеллектуальной "радужной таблицы", поэтому лучше использовать соль из серии псевдослучайных символов, хранящихся с хешированным паролем. В качестве иллюстрации, если бы у меня было имя пользователя "potato" и пароль "beer", объединенный ввод для вашего хэша - "potatobeer", что является разумной записью для радужной таблицы.
Изменение соли каждый раз, когда пользователь меняет свой пароль, может помочь отразить длительные атаки, а также применение разумной политики паролей, например, смешанный регистр, пунктуация, минимальная длина, изменение через n недель.
Однако я бы сказал, что ваш выбор алгоритма дайджеста важнее. Использование SHA-512 окажется более болезненным для кого-то, кто создает радужный стол, чем, например, MD5.
Я бы сказал, что если соль различна для каждого пароля, вы, вероятно, будете в порядке. Смысл в том, что вы не можете использовать стандартную радужную таблицу для определения каждого пароля в базе данных. Таким образом, если вы применяете различную соль для каждого пароля (даже если она не случайная), злоумышленнику в основном придется вычислять новую радужную таблицу для каждого пароля, поскольку каждый пароль использует свою соль.
Использование соли с большей энтропией не очень помогает, поскольку предполагается, что у злоумышленника в этом случае уже есть база данных. Поскольку вам нужно иметь возможность воссоздать хеш, вы уже должны знать, что такое соль. Таким образом, вы все равно должны хранить соль или значения, которые составляют соль, в вашем файле. В таких системах, как Linux, метод получения соли известен, поэтому нет смысла иметь секретную соль. Вы должны предположить, что злоумышленник, у которого есть ваши хеш-значения, вероятно, также знает ваши солт-значения.
Соль должна иметь как можно большую энтропию, чтобы гарантировать, что если данное входное значение будет хэшировано несколько раз, результирующее значение хеша будет, насколько это возможно, всегда отличаться.
Использование постоянно изменяющихся значений соли с максимально возможной энтропией в соли гарантирует, что вероятность хэширования (скажем, пароль + соль) приведет к совершенно другим значениям хеш-функции.
Чем меньше энтропии в соли, тем больше у вас шансов на генерирование того же солевого значения, как и, следовательно, больше шансов на генерирование того же хеш-значения.
Природа хэш-значения является "постоянной", когда входные данные известны, и "постоянной", что позволяет атакам по словарю или радужным таблицам быть настолько эффективными. Максимально варьируя полученное значение хеш-функции (используя высокие значения энтропийной соли), вы гарантируете, что хеширование одного и того же входного значения + случайной соли даст много разных результатов хеш-значения, тем самым побеждая (или, по крайней мере, значительно уменьшая эффективность) радужную таблицу атаки.
Энтропия - это точка солевого значения.
Если за солью есть какая-то простая и воспроизводимая "математика", то это то же самое, что соли нет. Просто добавление значения времени должно быть в порядке.