Я неправильно понимаю, что такое хэш-соль?

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

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

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

• секретный ключ, часто называемый «ключом»;
• переменный элемент, обычно выбираемый случайным образом и называемый «солью» или «IV» (как «начальное значение») в зависимости от типа алгоритма.

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

В контексте хранения хешированных паролей приведенное выше объяснение становится следующим:

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

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

openssl passwd -1 -salt "zap" "blah"

Это вычисляет хешированный пароль с хеш-функцией MD5, подходящей для использования в файле /etc/password или /etc/shadow, для пароля "blah" и соли "zap" (здесь я выбираю соль явно, но на практике она должна выбираться случайным образом). Результат тогда:

$1$zap$t3KZajBWMA7dVxwut6y921

в которых знаки доллара служат разделителями. Начальный "1" идентифицирует метод хеширования (MD5). Соль там, в виде открытого текста. Последняя часть — это вывод хеш-функции.

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

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

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

Если я вас правильно понял, то, похоже, вы все правильно поняли. Псевдокод процесса выглядит примерно так:

string saltedValue = plainTextValue + saltString;
// or string saltedalue = saltString + plainTextValue;

Hash(saltedValue);

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

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

Стоит отметить, что, несмотря на то, что соль должна быть разной для каждого использования пароля, ваша соль НИ В КОЕМ СЛУЧАЕ не должна вычисляться ИЗ самого пароля! Такого рода вещи имеют практический результат полной недействительности вашей безопасности.