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

  • Автор темы qpi3ik
  • 166
  • Обновлено
  • 18, May 2024
  • #1
Привет, Я работаю над системой входа в систему 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: Если кто-то здесь что-то знает, большое спасибо!

qpi3ik


Рег
29 Dec, 2014

Тем
1

Постов
3

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

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

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

леся3


Рег
18 Mar, 2013

Тем
0

Постов
2

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

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

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



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

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

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

drkronos


Рег
01 Jan, 2011

Тем
0

Постов
3

Баллов
3
  • 04, Jun 2024
  • #4
Я использую -1 для обозначения гостя, и если вход возвращает гостя, вы знаете, что это не удалось.

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

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

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

egor2957


Рег
04 Aug, 2015

Тем
0

Постов
3

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

Barnaul1


Рег
14 Feb, 2012

Тем
0

Постов
2

Баллов
2
  • 11, Jun 2024
  • #7
Не совсем, сэр.

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

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

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

indigo_88


Рег
17 Feb, 2013

Тем
0

Постов
3

Баллов
3
Тем
49554
Комментарии
57426
Опыт
552966

Интересно