Я натолкнулся на это утверждение
Не используйте функциональность «забытый пароль». Но если вы должны, убедитесь, что вы предоставляете информацию только фактическому пользователю, например, используя адрес электронной почты или вопрос о вызове, который уже предоставил законный пользователь в прошлом; не позволяйте текущему пользователю изменять эту идентификационную информацию до тех пор, пока не будет указан правильный пароль.
- Использование AJAX для передачи переменной в PHP и повторного получения тех, кто использует AJAX
- Как получить доступ к свойствам объекта с именами, такими как целые числа?
- Azure центр уведомлений PHP
- Лучший способ найти последний вставленный идентификатор в mysql, используя php
- php pdo: получить имя столбца таблицы
Может ли кто-нибудь объяснить, почему забытые пароли представляют собой риск? Я планирую обработать его, отправив пользователю ссылку в свой адрес электронной почты для сброса пароля, но не предоставит им старый пароль (так как он хэширован в любом случае), и не будет запрашивать у них старый пароль при сбросе. Есть ли что-то опасное в моем подходе?
Ваш подход абсолютно прав, если вы не храните пароль.
Вопрос об обеспечении безопасности является абсолютно плохим, так как он склонен к обходу только путем угадывания ответа.
Просто немного отредактируйте: хотя их может быть сложно поймать, вы должны попытаться запретить использование почтовых учетных записей mailinator (или адресов электронной почты из похожих служб), потому что mailinator + забыл пароль = катастрофа.
Если Чарли может читать электронную почту Alices, он также может получить доступ ко всем сайтам, предлагающим функциональность «потерянного пароля».
Самый обидный, техник будет следующим: Вы щелкаете забыл пароль, прошу вас по электронной почте и получить свой собственный пароль (который многие используют для пользователей порно и их онлайна-банкинга;)) назад в незашифрованном вместо установки нового.
Я бы просто скопировал методы больших игроков, например paypal или google. Думаю, теперь им нужно то, что они делают. Наиболее распространенным случаем является: забыли пароль – получите ссылку на электронную почту, где вы можете установить новую или создать случайный, безопасный (который пользователь сразу же вернется к 1234).
Поскольку мы уже там: никогда не возвращаем что-то вроде «неправильного пароля», так как это означает, что по крайней мере имя пользователя существует.
Отправка пользователю ссылки в электронном письме фактически соответствует приведенному руководству.
То, о чем идет речь, – это практика, позволяющая пользователям сбросить свой пароль без каких-либо дополнительных знаний, то есть что-то вроде кнопки, которая сбросит пароль, не заставляя пользователя нажимать на ссылку в своем письме. Я не уверен, что когда-либо видел такую систему, но это, безусловно, плохая идея =).
Ваш подход звучит очень безопасно для меня 🙂 Конечно, это должна быть разовая ссылка!
Также сообщение «succes» и «e-mail not found» должны быть одинаковыми. И иметь анонимный текст.
Подобно:
«Если ваш адрес электронной почты находится в нашей системе, мы отправим вам электронное письмо»
Таким образом, кто-то не сможет определить, находится ли адрес электронной почты в вашей системе или нет!
Пока вы отправляете ссылку на электронное письмо, которое вы сохранили в системе, тогда вы должны быть в порядке – и это то, что я ожидаю от системы.
Я также пришлю подтверждение «вы обновили пароль» по тому же адресу.
Кроме того, если пользователь меняет свой адрес электронной почты, вы можете отправить сообщение по электронной почте на старый адрес, указав, что он был изменен на новый . Немного раздражает, возможно, но это обеспечит дополнительный момент, когда кто-то может обнаружить, если их учетная запись была скомпрометирована.
Это довольно радикальное заявление и только плохая идея, если вы не понимаете связанных с этим рисков и уверены, что есть чистая прибыль (как и большинство вещей в жизни).
Вы никогда не должны хранить пароли в восстанавливаемой форме. Даже позволяя клиенту хранить подсказку в вашей системе, клиент рискует. Пароли всегда должны храниться с использованием необратимого механизма – то есть хеша. Учитывая это, вы не можете восстановить старый пароль клиента и отправить его им.
Сброс пароля по требованию на случайное значение, а затем отправка по электронной почте этого значения клиенту дает возможность проводить атаки на отказ в обслуживании для отдельных логинов (также случай, когда вы отключите учетную запись после нескольких неудачных попыток входа в систему).
Это только оставляет возможность генерировать альтернативный логин для клиента и отправлять по электронной почте им – и помечать учетную запись, чтобы заставить клиента выбрать новый пароль при следующем входе в систему.
Все эти подходы делегируют безопасность учетной записи клиента системе электронной почты клиентов (и всем другим почтовым и сетевым компонентам между вашим сервером и почтовым ящиком клиента), которые могут, в лучшем случае, быть очень негерметичными – конечно, это не то, что вы можете предоставить какие-либо гарантии безопасности, если вы не контролируете всю инфраструктуру.
C.