Как функция password_verify() получает соль из пароля, хранящегося в БД?

Я создаю простую форму регистрации и входа с использованием PHP. При регистрации я создаю хэш с помощью функции password_hash(), а затем сохраняю его в БД. Во время входа сначала я создал новый хеш, используя функцию password_hash(), а затем сравнил его с сохраненным хэшем пароля.

Это все время не удавалось, потому что, как я теперь понимаю, новая соль используется каждый раз, когда вы создаете хэш пароля с помощью функции password_hash(). После исследования я узнал, что нужно использовать PHP-функцию password_verify(<plain_text_password>,<password_fetched_from_DB>).

Чего я не понимаю, так это того, как функция password_verify знает значение соли, которое использовалось ранее во время регистрации? Если соль неизвестна, тогда password_verify также должен завершиться ошибкой, как функция password_hash, при использовании для сравнения.

Я прочитал об этом дальше и узнал, что когда функция password_hash() используется для создания хэша, она также сохраняет значение соли внутри хеша? Например, если созданный хэш равен abcde12345, то может ли 12345 быть солт-значением?

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

Выходные данные любой обычной функции хеширования паролей состоят из настроек сложности, соли и дайджеста пароля, закодированных в некоторый формат, указанный функцией хеширования паролей. Функция проверки ожидает такой же формат и просто считывает из него соль. Этот сайт имеет хорошее объяснение хеш-функций Argon2. Например, для argon2id (рекомендуемый вариант для PHP password_hash) с паролем 12345, соль qwertyuiop, 1 итерация, 1024 памяти, длина хеша 32, параллелизм 1, вывод будет $argon2id$v=19$m=1024,t=1,p=1$cXdlcnR5dWlvcA$dSEO3lF0tmBRi3/HZFZqPJGv38CW35xf9Fcs+8ti0yk

Вы можете увидеть различные параметры, разделенные $ знаки.

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

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

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