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