Почему «забытый пароль» плох? - PullRequest
14 голосов
/ 21 июня 2010

Я сталкивался с этим заявлением

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

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

Ответы [ 7 ]

12 голосов
/ 21 июня 2010

Ваш подход абсолютно верен, если вы не храните пароль.

Вместо этого задавать секретный вопрос абсолютно плохо, поскольку его можно обойти, просто угадав ответ.

Просто немного отредактируйте: хотя может быть трудно поймать их все, вы должны попытаться запретить использование учетных записей электронной почты mailinator (или адресов электронной почты из аналогичных служб), потому что mailinator + забыл пароль = катастрофа.

4 голосов
/ 21 июня 2010

Если Чарли может читать электронную почту Аликеса, он также может получить доступ ко всем сайтам, предлагающим функцию «потерянного пароля».

3 голосов
/ 21 июня 2010

Самое обидное техника будет следующим: вы щелкаете забыли пароль, просят вас по электронной почте и получить свой собственный пароль (который многие используют пользователя для порно и их онлайн-банкинга;)) назад в незашифрованном вместо установки нового .

Я бы просто скопировал методы крупных игроков, такие как PayPal или Google. Я думаю, что они должны сейчас, что они делают. Наиболее распространенным случаем должно быть: забытый пароль - получите ссылку на свой адрес электронной почты, где вы можете установить новый или создать случайный, безопасный (который пользователь сразу же изменит на 1234).

Поскольку мы уже там: никогда не возвращайте что-то вроде «неправильного пароля», поскольку это подразумевает, что, по крайней мере, имя пользователя существует.

2 голосов
/ 21 июня 2010

Это довольно широкое утверждение и плохая идея, если вы не понимаете связанных с этим рисков и уверены, что есть чистая выгода (как и в большинстве случаев в жизни).

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

Сброс пароля по требованию на случайное значение, затем отправка этого значения по электронной почте клиенту дает возможность перенестиисключение атак типа «отказ в обслуживании» на отдельные учетные записи (также в случае отключения учетной записи после нескольких неудачных попыток входа в систему).

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

Все эти подходы делегируют безопасность учетной записи клиента системе электронной почты клиента (и всем остальным компонентам электронной почты и сети между вашимсервер и входящий почтовый ящик клиента), который в лучшем случае может быть очень негерметичным - безусловно, это не что-то, что вы можете обеспечить какими-либо гарантиями безопасности, если вы не контролируете всю инфраструктуры.1013 *

2 голосов
/ 21 июня 2010

Пока вы отправляете ссылку на электронное письмо, которое вы сохранили в системе, у вас все будет в порядке - и это то, что я ожидаю от системы.

Я бы также отправил подтверждение «Вы обновили свой пароль» на тот же адрес.

Кроме того, если пользователь меняет свой адрес электронной почты, вы можете рассмотреть возможность отправки сообщения электронной почты на старый адрес с указанием того, что оно было изменено на новый . Возможно, это немного раздражает, но это даст дополнительный момент, когда кто-то сможет определить, была ли взломана его учетная запись.

2 голосов
/ 21 июня 2010

Отправка пользователю ссылки в электронном письме фактически соответствует приведенным инструкциям.

Что он советует, так это практика, позволяющая пользователям сбрасывать свой пароль без необходимости иметь какие-либо дополнительные знания, то есть что-то вроде кнопки, которая сбрасывает пароль, не заставляя пользователя нажимать ссылку в своем электронном письме. Я не уверен, что когда-либо видел такую ​​систему, но это, безусловно, плохая идея =).

2 голосов
/ 21 июня 2010

Ваш подход звучит для меня очень безопасно :) Конечно, это должна быть разовая ссылка!

Также сообщение / страница "succes" и "email address not found" должны совпадать. И иметь анонимный текст.

как:

«Если ваш почтовый адрес находится в нашей системе, мы отправили вам электронное письмо»

Таким образом, кто-то не сможет определить, находится ли адрес электронной почты в вашей системе или нет!

...