Можно ли хранить соли с помощью хешей?

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

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

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

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

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

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

Ответ 1

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

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

Вы можете сохранить соль в "plain-text" в таблице.

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

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

изменить:

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

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

Ответ 5

Ваше второе решение "Соль на каждый сохраненный пароль" является правильным и обычно используется.

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

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

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

Это почти dup wtb: хеширование паролей, соль и хранение хешированных значений