Это хороший способ реализовать "забыл пароль"?особенность?

Question

В настоящее время я разрабатываю небольшой веб-сайт, и я хотел бы реализовать «забыли пароль?» особенность. Вот моя идея:

забыл ваш пароль, на веб-странице будет:

Email: (input box)
(button: "Make temp password")

При нажатии кнопки «Создать временный пароль»:

1. Очистить ввод электронной почты для SQLi / XSS
2. Убедитесь, что адрес электронной почты существует в базе данных.
   • если нет, попросить пользователя создать новую учетную запись или проверить правописание электронной почты
3. Создайте случайный пароль (т.е. «xh5MvQe») и поместите его в базу данных в поле временного пароля пользователя.
   • перезаписать, если уже существует. не трогайте основной пароль. пользователь сможет войти в систему с двумя паролями в течение следующих 48 часов.
4. Получите текущее время UTC плюс 48 часов и поместите его в поле даты истечения временного пароля пользователя в базе данных. перезаписать, если уже существует.
5. Отправить письмо пользователю с временным паролем

В моей базе данных есть следующие поля для пользовательской таблицы:

(primary key) user id
name
nickname
(non null, unique) email
(non null) password (encrypted)
temporary password
temporary password expiration

Получив пароль, пользователь может войти в систему и изменить свой основной пароль.

Вопрос: это безопасный способ реализации этой функции? Моя главная задача - отправка простого текстового пароля по электронной почте. Я видел другой способ создания ссылки с хэшем электронной почты / меткой времени / случайным идентификатором в качестве параметра GET, но я не вижу, насколько это более безопасно. Пожалуйста, поправьте меня, если я ошибаюсь.

Answer 1

Прочитайте это: Полное руководство по аутентификации веб-сайтов на основе форм

Плохо отправлять пользователям какие-либо пароли, потому что вы не можете быть уверены, что его учетная запись компьютера / электронной почты/ будет в безопасности.Если вы генерируете и отправляете пароль, пользователь может не изменить его.Вы не можете не посылать какой-то идентификационный токен для восстановления, так что срок действия - хорошая идея.

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

Итак, это способ избежать сохраненияобычные текстовые пароли на компьютере пользователя:

1. Очистить ввод электронной почты для SQLi / XSS
2. Убедитесь, что адрес электронной почты существует в базе данных
   • , если нет,попросить пользователя создать новую учетную запись или проверить правописание электронной почты
3. Создать случайный токен для входа в систему восстановления (например, «xh5MvQe») и поместить его хэш в базу данных в поле хэша восстановления пароля пользователя.
   • перезаписать, если он уже существует.не трогайте основной пароль.Пользователь сможет
     • войти со своим старым паролем, удалив хэш восстановления.
     • войти с паролями токена восстановления один раз , в течение следующих 48 часов, который заставляет пользователя выбрать новый пароль.
4. Получить текущее время UTC плюс 48 часов [...]
5. Отправить письмопользователю со ссылкой для одноразового восстановления логина.

Answer 2

Я думаю, что ваша система psuedo безопасна, я бы добавил шаг 6, который будет очищать временный пароль, когда пользователь действительно изменит свой действительный пароль. Если вы беспокоитесь о незашифрованном электронном письме, вам нужно убедиться, что временный пароль недоступен в течение 48 часов даже после того, как пользователь успешно изменил свой пароль.

Answer 3

Это довольно необычный способ.
В большинстве случаев отправляется гиперссылка, а не сам пароль.

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

Также я не вижу смысла в очистке электронной почты от XSS.
И "очистка ввода электронной почты для SQLi" звучит для меня странно как отдельный шаг.Разве необходимая подготовка не является локальной частью создания SQL-запроса?Почему это оказалось частью глобального алгоритма?

Итак, для меня это выглядит как алгоритм из двух частей:

1. Попросите пользователя ввести свою электронную почту.
2. Проверьте, существует ли адрес электронной почты вбаза данных
3. Если это так, отправьте гиперссылку на это письмо

с кодом, подобным этому

$salt  = "35onsoi2e=-7#%3%g03skl";
$time  = time();
$hash  = MD5($_POST['email'].$time.$salt);
$email = urlencode($_POST['email']);
$link  = "http://example.com/register.php?email=$email&time=$time&hash=$hash";

После нажатия на ссылку пользователь попадает на пароль восстановленияскрипт, который

1. Проводит проверки с использованием того же алгоритма хеширования.
2. Проверяет время истечения.
3. , если все в порядке, предлагает пользователю ввести новый пароль
4. Сброс пароля в базе данных.