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

Question

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

Answer 1

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

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

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

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

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

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

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

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

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

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

$1$zap$t3KZajBWMA7dVxwut6y921

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

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

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

Answer 2

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

Answer 3

Если я вас правильно понимаю, звучит так, будто вы все правильно поняли. Psuedocode для процесса выглядит примерно так:

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

Hash(saltedValue);

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

Answer 4

Стоит отметить, что хотя соль должна быть разной для каждого использования пароля, ваша соль НИКОГДА НЕ ДОЛЖНА быть вычислена ОТ самого пароля! Подобные вещи имеют практическое следствие полной аннулирования вашей безопасности.

Answer 5

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