Можно ли хранить соли с хэшами?

Question

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

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

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

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

Мой вопрос: это приемлемо? Есть ли дополнительный риск, связанный с хранением соли непосредственно с паролем, который она хэширует? Мне кажется, что хранение соли в исходном коде ничем не отличается, поэтому при сохранении соли с паролем нет потери безопасности.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я не использую это для любой реальной системы безопасности. На самом деле, я никогда не проектировал систему паролей. Я просто держу себя смутно в курсе вопросов безопасности.

Answer 1

обновление : используйте компетентную библиотеку, например passlib для Python.

Они заботятся о генерации соли для каждого пароля и используют надлежащий алгоритм хеширования (недостаточно просто использовать криптографический хеш, такой как SHA1; вы должны применять его так, чтобы сделать его очень медленным, например: зацикливание 1000 и более раз и т. д. Вот как работают хеш-функции паролей, такие как bcrypt * 1008. * Библиотеки хранения паролей делают все это правильно, они обычно создают строку с разделителями, чтобы они могли определить хэш-систему и работать используемый фактор, вы просто сохраняете строку без необходимости знать это.

<Ч />

Вы можете хранить соль в виде простого текста в таблице.

• Соль не должна быть секретной, чтобы быть эффективной

• это просто должно быть случайным.

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

В основном: более длинный (в байтах) пароль + соль увеличивает пространство поиска и, таким образом, усложняет использование «стандартных» радужных таблиц.

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

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

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

Если вы хотите использовать первичный ключ, вероятно, будет хорошей идеей взять хэш первичного ключа, а не использовать сам первичный ключ, потому что если пароль + соль для пользователя 43 выглядит следующим образом «myPassword00000000043», то злоумышленник может построить таблицу с предположением, что в середине много нулей. Тем не менее, временные метки создания и случайная строка, вероятно, являются лучшими вариантами, поскольку PKeys иногда можно легко найти или угадать.

Примечание: я не настоящий специалист по шифрованию, не используйте этот совет в реальной системе.

Answer 5

Ваше второе решение «Хранить соль на пароль» является правильным и обычно используется.

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

Таким образом, обычно вы генерируете случайную соль и сохраняете ее с паролем ИЛИ в качестве соли вы используете другой идентификатор (идентификатор пользователя, имя пользователя и т. Д.).

Answer 6

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

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

редактирование:

Предполагая, что вы новичок в криптографии, вот еще несколько советов:

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

Answer 7

У вас уже есть солт-значение, хранящееся в пользовательской таблице: ключ таблицы.

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

Это почти двойной код: Хэширование пароля, соль и хранение хэшированных значений