логин-система, проверка PWD (+salt) не работает, 2 разных хеша

Привет, Я работаю над системой входа в систему PHP на основе онлайн-учебника. (Я так близок к тому, чтобы закончить это!!) Я использую одну и ту же функциональность для создания PWD и его проверки, но, тем не менее, у меня разные хеши.

Я сфотографировал результат, который получаю: Соль для проверки - это соль из БД, я также сохранил незашифрованный PWD() в базе данных, чтобы проверить, есть ли там ошибка, но нет ошибки (желтая линия) Оба хеша (черный и красный) не совпадают.

Очевидно, что наличие соли не может быть причиной проблемы!! Это моя проверочная функция:

  class Hash {

public static function make($string,$salt = '') {

return hash('sha256',$string.$salt);

}

public static function salt($length) {

return random_bytes($length);

}

public static function unique() {

return self::make(uniqid());

}

}

PHP: Возможно, проблема в моем классе Hash, методе make, понятия не имею???

  if($this->data()->password === Hash::make($password,$this->data()->salt)) { echo 'OK';

PHP: Если кто-то здесь что-то знает, большое спасибо!

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

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

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

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

Если вы поместите это в таблицу, вы совершенно, полностью и ПОЛНОСТЬЮ лишитесь смысла даже есть соль.

Что касается реальной проблемы, то проблема может заключаться в использовании символов за пределами ASCII7, поскольку только Кристмас знает, что движок SQL и PHP собираются делать с манипулированием кодировкой символов!



W base64 из некоторых случайных_байтов даст гораздо лучший хеш, чем этот крушение поезда из символов, которые не укладываются в пространство символов ASCII7! Вы выходите за пределы кодов символов 32..127, и черт знает, чем могут закончиться эти случайные значения, например, когда в миксе присутствуют такие вещи, как UTF-8. Хотя это может быть пережитком компьютерного менталитета 1960-х годов, шестибитное кодирование Base64, вероятно, позволило бы избежать любой проблемы, которая здесь возникает.

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

Поэтому я бы полностью исключил весь этот дерьмовый класс «Hash».

Я использую -1 для обозначения гостя, и если вход возвращает гостя, вы знаете, что это не удалось.

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

В лучшем случае, если бы я беспокоился о безопасности, я бы заменил sha256 на sha512 или на водоворот.

и снова использовал глобальную соль вместо того, чтобы пытаться создать уникальную соль в БД.

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

Почему бы просто не использовать встроенные функции для хеширования и проверки паролей?
https://www.php.net/manual/en/book.password.php

Не совсем, сэр.

Это усложняет взлом паролей.

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

Но учтите, что идея шифрования в первую очередь состоит в том, чтобы просто усложнить жизнь неавторизованным пользователям, пытающимся получить доступ. При этом я вообще не использую соли.