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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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