Я столкнулся с этим statement
Не используйте "забытый пароль" функциональность. Но если вам нужно, что вы только предоставляете информации фактическому пользователю, например. используя адрес электронной почты или вызов вопрос о том, что законный пользователь уже предоставленные в прошлом; не разрешить текущему пользователю изменять это идентификационной информации до тех пор, пока пароль был предоставлен.
Может кто-нибудь уточнить, почему забытые пароли представляют собой риск? Я планирую обработать его, отправив пользователю ссылку в свой адрес электронной почты на reset пароль, но не предоставит им старый пароль (так как он хэширует в любом случае) и не будет запрашивать у них старый пароль при сбросе. Есть ли что-то опасное в моем подходе?
Ваш подход абсолютно прав, если вы не храните пароль.
Задавая вопрос безопасности, это абсолютно плохо, поскольку он склонен к обходу только путем угадывания ответа.
Просто немного отредактируйте: хотя может быть сложно поймать всех из них, вы должны попытаться запретить использование почтовых учетных записей mailinator (или адресов электронной почты из похожих служб), потому что mailinator + забыл пароль = катастрофа.
Если Чарли может читать электронную почту Алиса, он также может получить доступ ко всем сайтам, предлагающим функциональность "потерянного пароля".
Самое обидное техника будет следующим: вы щелкаете забыли пароль, просят вас по электронной почте и получить свой собственный пароль (который многие используют пользователя для порно и их онлайн-банкинга;)) назад в незашифрованном вместо установки нового.
Я бы просто скопировал методы больших игроков, например paypal или google. Думаю, теперь им нужно то, что они делают. Наиболее распространенным случаем является: забыли пароль - получите ссылку на электронную почту, где вы можете установить новую или создать случайный, безопасный (который пользователь сразу же вернется к 1234).
Как мы уже там: никогда не возвращай что-то вроде "неправильного пароля", так как это означает, что существует хотя бы имя пользователя.
Ваш подход звучит очень безопасно для меня:) Конечно, это должна быть разовая ссылка!
Также сообщение/страница "succes" и "e-mail not found" должны совпадать. И иметь анонимный текст.
Как
"Если ваш почтовый адрес находится в нашей системе, мы отправим вам электронное письмо"
Таким образом, кто-то не сможет определить, находится ли адрес электронной почты в вашей системе или нет!
Отправка пользователю ссылки в электронном письме фактически соответствует приведенному руководству.
То, что он советует против, - это практика предоставления пользователям пароля reset без необходимости иметь какие-либо дополнительные знания, то есть что-то вроде кнопки, которая будет reset пароль, не заставляя пользователя нажимать ссылку в своем письме, Я не уверен, что когда-либо видел такую систему, но это, безусловно, плохая идея =).
Пока вы отправляете ссылку на электронное письмо, которое вы сохранили в системе, тогда вы должны быть в порядке - и это то, что я ожидал бы от системы.
Я также пришлю подтверждение "вы обновили пароль" по тому же адресу.
Кроме того, если пользователь изменяет свой адрес электронной почты, вы можете отправить сообщение по электронной почте на старый адрес, указав, что он был изменен на новый. Немного раздражает, возможно, но это обеспечит дополнительный момент, когда кто-то может обнаружить, если их учетная запись была скомпрометирована.
Это скорее радикальное утверждение и только плохая идея, если вы не понимаете связанных с этим рисков и уверены, что есть чистая выгода (как и в большинстве вещей в жизни).
Вы никогда не должны хранить пароли в восстанавливаемой форме. Даже позволяя клиенту хранить подсказку в вашей системе, клиент рискует. Пароли всегда должны храниться с использованием необратимого механизма, т.е. Хеша. Учитывая, что это так, вы не можете восстановить старый пароль клиента и отправить его им.
Сброс пароля по требованию на случайное значение, а затем отправка этого значения клиенту дает возможность проводить атаки на отказ в обслуживании для отдельных логинов (также случай, когда вы отключили учетную запись после нескольких неудачных попыток входа в систему)).
Это оставляет только возможность генерировать альтернативный логин для клиента и отправлять его по электронной почте - и помечать учетную запись, чтобы заставить клиента выбрать новый пароль при следующем входе в систему.
Все эти подходы делегируют безопасность учетной записи клиента системе электронной почты клиентов (и всем другим почтовым и сетевым компонентам между вашим сервером и почтовым ящиком клиента), которые могут, в лучшем случае, быть очень негерметичными - конечно, это не то, что вы можете предоставляйте любые гарантии безопасности, если вы не контролируете все инфраструктуры.
С.