Как правильно реализовать hash_hmac? - PullRequest
3 голосов
/ 07 апреля 2011

Чтение этот отличный ответ о хешировании пароля и о том, как его реализовать:

Злая Блоха писал (а):

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

Так, кроме пароля пользователя, хранить уникальный токен в моей базе данных?

Пример кода в оригинальном сообщении:

function hash_password($password, $nonce) {
  global $site_key;
  return hash_hmac('sha512', $password . $nonce, $site_key);
}

Как я могу проверить пароль с помощью этого кода? Позвольте мне объяснить:

Когда пользователь отправляет свой пароль, мне нужно сгенерировать его хэш, чтобы проверить существующую строку базы данных, где адреса электронной почты и совпадают с хеш-паролем. Как я могу выбрать эту строку, когда я ничего не знаю о пользователях $nonce? Я что-то пропустил? Может быть, мне нужно выбрать пользователя только по его адресу электронной почты, а затем проверить хэш пароля?

Кстати, вы рекомендуете этот метод хеширования?

1 Ответ

3 голосов
/ 07 апреля 2011

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

Вам решать, доверяете ли вы своему серверу БД (и подключению к нему), использовать алгоритм хеширования, поддерживаемый БД, и позволить БД выполнять математические вычисления:

SELECT * FROM users WHERE email = 'email' AND password = SHA1(CONCAT('cleartextpass',nonce));

Или вы можете сделать математику в коде после получения всех соответствующих писем.

EDIT : комментарий ThiefMaster о разграничении между отсутствующим пользователем и неверным паролем - это классический недостаток безопасности, который позволяет злоумышленникам получить список действительные имена пользователей и сосредоточиться на взломе их паролей вместо рыбалки в темноте. Я настоятельно рекомендую против . 1018 *

...