Я неправильно понимаю, какова соль хеша?
Я работаю над добавляющим обзором хеша, генерирующим функциональность к нашей кодовой базе. Я хотел использовать Строку в качестве соли хеша так, чтобы предварительно известный ключ/пароль мог предварительно ожидаться к тому, чем это было, который должен был быть хеширован. Я неправильно понимаю это понятие?
5 ответов
Соль - это случайный элемент, который добавляется на вход криптографической функции с целью воздействия на обработку и вывод особым образом при каждом вызове. Соль, в отличие от "ключа", не является конфиденциальной.
Сто лет назад криптографические методы шифрования или аутентификации были "секретными". Тогда, с появлением компьютеров, люди поняли, что хранить метод в полном секрете трудно, потому что это означало сохранять конфиденциальность самого программного обеспечения. Что-то, что регулярно записывается на диск или воплощается как некое специализированное оборудование, трудно сохранить в тайне. Поэтому исследователи разделили "метод" на два разных понятия: алгоритм (который является открытым и становится программно-аппаратным) и ключ (параметр к алгоритму, присутствующий в переменной оперативной памяти только во время обработки). Ключ концентрирует секрет и является чистыми данными. Когда ключ хранится в мозгу человека, его часто называют "паролем", потому что человек лучше запоминает слова, чем биты.
Тогда сам ключ позже был разделен. Оказалось, что для правильной криптографической защиты нам нужны две вещи: конфиденциальный параметр и переменный параметр. В принципе, повторное использование одного и того же ключа для различных целей, как правило, создает проблемы; это часто приводит к утечке информации. В некоторых случаях (особенно для шифров потоков, но и для хэширования паролей), это приводит к слишком большим утечкам и успешным атакам. Поэтому часто возникает потребность в вариабельности, которая меняется каждый раз, когда запускается криптографический метод. Сейчас хорошо то, что в большинстве случаев вариабельность и секретность не нужно сливать воедино. То есть, мы можем отделить конфиденциальный от переменной . Таким образом, ключ был разделен на:
- -секретный ключ, часто называемый "ключом";
- -переменный элемент, обычно выбираемый случайным образом, и называемый "солью" или "IV" (как "Начальное значение") в зависимости от типа алгоритма.
Только ключ должен быть секретным. Элемент переменной должен быть известен всем вовлеченным сторонам, но он может быть публичным. Это благословение, потому что обмен секретным ключом затруднен; системы, используемые для распространения такого секрета, посчитали бы дорогостоящим размещение переменной части, которая изменяется каждый раз при запуске алгоритма.
В контексте хранения хэшированных паролей вышеприведенное объяснение становится следующим:
- "Повторное использование ключа" означает, что два пользователя случайно выбирают один и тот же пароль. Если пароли просто хэшируются, то оба пользователя получат одно и то же значение хэша, и это покажет. Вот утечка.
- Аналогично, без хэша атакующий может использовать предварительно вычисленные таблицы для быстрого поиска; он также может параллельно атаковать тысячи паролей. При этом используется та же самая утечка, только таким образом, чтобы показать, почему эта утечка плохая.
- Соление означает добавление на вход хэш-функции некоторых переменных данных. Эти переменные данные - соль. Смысл соли в том, что два разных пользователя должны использовать, насколько это возможно, различные соли. Но парольные верификаторы должны иметь возможность пересчитывать один и тот же хэш из пароля, поэтому они должны иметь доступ к соли.
Поскольку соль должна быть доступна для верификаторов, но не должна быть секретной, принято хранить значение соли вместе со значением хэша. Например, в системе Linux я могу использовать эту команду:
openssl passwd -1 -salt "zap" "blah"
Это вычисляет хэш-пароль с помощью хэш-функции MD5, подходящий для использования в файле /etc/password или /etc/shadow, для пароля "бла" и соли "зап" (здесь я выбираю соль явно, но в практических условиях она должна быть выбрана случайным образом). Выходом будет:
$1$zap$t3KZajBWMA7dVxwut6y921
, в котором знаки доллара служат разделителями. Исходный "1" идентифицирует метод хеширования (MD5). Соль находится там, в четкой текстовой нотации. Последняя часть - выход хэш-функции.
Есть спецификация (где-то), как соль и пароль посылаются на вход хэш-функции (по крайней мере, в исходном коде glibc, возможно, где-то еще).
Редактирование: в системе аутентификации пользователей "login-and-password", "login" может действовать как соль для прохода (два разных пользователя будут иметь разные логины), но это не фиксирует ситуацию, когда данный пользователь меняет свой пароль (утечка информации о том, идентичен ли новый пароль старому, будет утечка).
Использование DOLLAR прост в виде набора:
@Test
public void repeatString() {
String string = "abc";
assertThat($(string).repeat(3).toString(), is("abcabcabc"));
}
PS: Повторяется Работает также для массива, списка, набора и т. Д.
-121--1793581-И еще лучше, если соль отличается от каждой зашифрованной фразы, поскольку каждая соль требует собственного радуга.
Если я правильно тебя понимаю, похоже, ты все правильно понял. Пседокод для этого процесса выглядит так:
string saltedValue = plainTextValue + saltString;
// or string saltedalue = saltString + plainTextValue;
Hash(saltedValue);
Соль просто добавляет еще один уровень сложности для людей, пытающихся получить от вас информацию.
Вы прекрасно понимаете концепцию. Просто убедитесь, что приготовленная соль повторяется каждый раз.
Стоит отметить, что несмотря на то, что соль должна быть разной для каждого использования пароля, ваша соль НЕ ДОЛЖНА быть вычислена с самого пароля! Такие вещи имеют практический вывод о полной недействительности вашей безопасности.