Реализуйте лучшую практику восстановления пароля

Я хочу для реализации восстановления пароля в моем веб-приложении.

Я хотел бы избегать использования секретных вопросов.

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

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

Я могу отправить URL по электронной почте, например, http://example.com/token=xxxx, где xxxx является случайным маркером, связанным с пользователем. Таким образом, когда пользователь перешел к тому URL, он может изменить пароль.

62
задан Cœur 29 December 2016 в 17:08
поделиться

5 ответов

Во-первых, не не храните текстовую копию пароля пользователя или даже его зашифрованную версию. Вы хотите всегда хранить только хешированную копию пароля пользователя.

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

49
ответ дан 24 November 2019 в 16:34
поделиться

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

10
ответ дан 24 November 2019 в 16:34
поделиться

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

Однако то, что вы не должны делать :

  • Отправьте пароль - в конце концов, как уже упоминалось, у вас его нет.

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

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

Конечно, многое зависит от приложения. Очевидно, что защита финансовой и другой конфиденциальной информации более важна, чем предотвращение взлома вашей учетной записи на mytwitteringfacetube.com, потому что, хотя это и неудобно, если кто-то хочет украсть чью-то личность на сайте социальной сети, он может просто открыть свою учетную запись и замаскироваться под украденным информация в любом случае.

20
ответ дан 24 November 2019 в 16:34
поделиться

Когда я служил в ВВС, у нас было правило безопасности: при установке или сбросе паролей не отправляйте идентификатор пользователя и пароль в одном и том же Эл. адрес. Таким образом, если кто-то перехватывает электронные письма в поисках паролей, он должен успешно перехватывать ОБЕИМ электронные письма и иметь возможность подключать их, чтобы нарушить безопасность.

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

Кстати, поздравляю, что НЕ используете контрольные вопросы. Логика этого устройства ускользает от меня.С самого начала компьютерной безопасности мы говорили людям: «НЕ создавайте пароль, который представляет собой информацию о вас, которую хакер может обнаружить или угадать, например, название вашей средней школы или ваш любимый цвет. Хакер может чтобы найти название вашей средней школы, или даже если они не знают вас или ничего о вас не знают, если вы все еще живете недалеко от того места, где ходили в школу, они могут получить его, пробуя местные школы, пока они не дойдут до него. небольшое количество вероятных любимых цветов, чтобы хакер мог это догадаться. И т. д. Вместо этого пароль должен представлять собой бессмысленную комбинацию букв, цифр и знаков препинания ". Но теперь мы также говорим им: «Но! Если вам трудно запомнить эту бессмысленную комбинацию букв, цифр и знаков препинания, не проблема! Возьмите некоторую информацию о себе, которую вы легко запомните - например, название вашей средней школы. , или ваш любимый цвет - и вы можете использовать это в качестве ответа на «секретный вопрос», то есть в качестве альтернативного пароля »

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

Вместо вопросов безопасности, почему бы нам просто не сказать: «Если вы забудете свой пароль, он отобразится в нижней части экрана. Если вы пытаетесь взломать чужую учетную запись, вы абсолютно запрещено прокручивать страницу вниз ". Это было бы немного менее безопасно.

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

85
ответ дан 24 November 2019 в 16:34
поделиться

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

"Секретные" вопросы и ответы - это просто другая форма имени пользователя и пароля с тем фатальным недостатком, что их обычно невероятно легко угадать, настолько хорошо, что вы не захотите их использовать.

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

Просто убедитесь, что токен можно использовать только один раз и, желательно, только в ограниченный промежуток времени, например, +24 часа после запроса.

И, как указывалось в предыдущих ответах, НИКОГДА не храните простые пароли. Хешируйте их. Желательно добавлять salt.

4
ответ дан 24 November 2019 в 16:34
поделиться
Другие вопросы по тегам:

Похожие вопросы: