Неслучайная соль для хэшей паролей
обновление: я недавно узнал от этот вопрос что во всей дискуссии ниже, я (и я уверен, что другие тоже) был немного запутанным: то, что я продолжаю называть радужной таблицей, на самом деле называется хэш-таблицей. Радужные таблицы-это более сложные существа, и на самом деле это вариант хэш-цепочек Hellman. Хотя я считаю, что ответ все тот же (поскольку он не сводится к криптоанализу), некоторые из обсуждений могут быть немного искажены.
Вопрос: "что такое радужные таблицы и как они используются?"
Как правило, я всегда рекомендую использовать криптографически сильное случайное значение в качестве соли, которое будет использоваться с хэш-функциями (например, для паролей), например, для защиты от атак радужных таблиц.
но действительно ли криптографически необходимо, чтобы соль была случайной? Достаточно ли в этом отношении какого-либо уникального значения (уникального для каждого пользователя, например userId)? Это фактически предотвратило бы использование одной радуги Таблица для взлома всех (или большинства) паролей в системе...
Но действительно ли отсутствие энтропии ослабляет криптографическую силу хэш-функций?
обратите внимание, я не спрашиваю о том, почему использовать соль, как ее защитить (это не обязательно), используя один постоянный хэш (не нужно) или какую хэш-функцию Использовать.
Просто нужна ли соли энтропия или нет.
спасибо всем за ответы до сих пор, но я хотел бы сосредоточиться на областях, в которых я (a немного) менее знакомый. В основном последствия для криптоанализа-я был бы признателен, если бы у кого-то был какой-то вклад от крипто-математического PoV.
Кроме того, если есть дополнительные векторы, которые не были рассмотрены, это тоже отличный вход (см. точку @Dave Sherohman на нескольких системах).
Кроме того, если у вас есть какая - либо теория, идея или лучшая практика-Пожалуйста, поддержите это либо доказательством, сценарием атаки, либо эмпирическими доказательствами. Или даже действительные соображения для приемлемого компромиссы... Я знаком с лучшей практикой (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 наиболее часто используемым именам пользователей. Это скорее всего, некоторые из ваших пользователей будут выбирать имя пользователя, которое принадлежит к наиболее распространенным именам пользователей.
Я нашел это проверка пароля что энтропия пароля. Наличие меньшей энтропии в паролях (например, с помощью имен пользователей) значительно облегчает радужные таблицы, поскольку они пытаются покрыть, по крайней мере, все пароли с низкой энтропией, потому что они более вероятны.
Это правда, что только имя пользователя может быть проблематичным, так как люди могут делиться именами пользователей между различными веб-сайтами. Но это должно быть довольно беспроблемно, если у пользователей было другое имя на каждом веб-сайте. Так почему бы просто не сделать его уникальным на каждом веб-сайте. Хэш пароль примерно так
hashfunction("www.yourpage.com/" + username+"/ " +password)
Это должно решить проблему. Я не мастер криптоанализа, но я уверен, что сомневаюсь в том, что мы этого не делаем использование высокой энтропии сделает хэш слабее.
Мне нравится использовать оба: высокоэнтропийную случайную соль на запись, а также уникальный идентификатор самой записи.
хотя это не добавляет много к безопасности от словарных атак и т. д., он удаляет крайний случай, когда кто-то копирует свою соль и хэш в другую запись с намерением заменить пароль своим собственным.
(по общему признанию, трудно думать об обстоятельствах, когда это применимо, но я не вижу никакого вреда в ремнях и скобках, когда дело доходит до безопасность.)
Если соль известна или легко угадывается, вы не увеличили сложность атаки по словарю. Возможно даже создать модифицированную радужную таблицу, которая учитывает "постоянную" соль.
использование уникальных солей увеличивает сложность массовых атак словаря.
иметь уникальное, криптографически сильное значение соли было бы идеально.
Я бы сказал, что пока соль для каждого пароля, вы, вероятно, будет ОК. Суть соли в том, что вы не можете использовать стандартную радужную таблицу для решения каждого пароля в базе данных. Поэтому, если вы применяете другую соль к каждому паролю (даже если это не случайно), злоумышленнику в основном придется вычислить новую радужную таблицу для каждого пароля, поскольку каждый пароль использует другую соль.
использование соли с большей энтропией не очень помогает, потому что злоумышленник в этом случае, как предполагается, уже есть база данных. Так как вы должны быть в состоянии воссоздать хэш, вы должны уже знать, что такое соль. Таким образом, вы должны хранить соль или значения, которые составляют соль в вашем файле в любом случае. В таких системах, как Linux, метод получения соли известен, поэтому нет смысла иметь секретную соль. Вы должны предположить, что злоумышленник, у которого есть ваши хэш-значения, вероятно, также знает ваши значения соли.
сила хэш-функции не определяется ее входом!
использование соли, которая известна злоумышленнику, очевидно, делает построение радужной таблицы (особенно для жестко закодированных имен пользователей, таких как root) более привлекательным, но это не ослабит хэш. Использование соли, которая неизвестна злоумышленнику, затруднит атаку на систему.
объединение имени пользователя и пароля может по-прежнему предоставлять запись для интеллектуальная радужная таблица, поэтому использование соли из серии псевдослучайных символов, хранящихся с хэшированным паролем, вероятно, является лучшей идеей. В качестве иллюстрации, если бы у меня было имя пользователя "картофель" и пароль "пиво", объединенный вход для вашего хэша - "potatobeer", что является разумной записью для радужной таблицы.
изменение соли каждый раз, когда пользователь меняет свой пароль, может помочь победить длительные атаки, как и применение разумной политики паролей, например смешанной регистр, пунктуация, минимальная длина, изменение после n недель.
однако, я бы сказал, что ваш выбор алгоритма дайджеста более важен. Использование SHA-512 окажется более болезненным для кого-то, создающего радужную таблицу, чем MD5, например.
соль должна иметь как можно больше энтропии, чтобы гарантировать, что если заданное входное значение будет хэшироваться несколько раз, результирующее значение хэша будет, насколько это возможно, всегда отличаться.
использование постоянно меняющихся значений соли с максимально возможной энтропией в соли гарантирует, что вероятность хэширования (скажем, пароль + соль) приведет к совершенно другим значениям хэша.
чем меньше энтропии в соли, тем больше у вас шансов на создание то же значение соли, так как, таким образом, больше шансов у вас есть для генерации того же значения хэша.
Это природа хэш-значения, являющегося "константой", когда вход известен и" константа", которые позволяют атакам словаря или радужным таблицам быть настолько эффективными. Варьируя полученное значение хэша как можно больше (используя значения соли с высокой энтропией), гарантирует, что хэширование одного и того же входа+random-salt даст много разных результатов хэш-значения, тем самым победив (или, по крайней мере, значительно уменьшив эффективность) радужная таблица атак.