Эффективные методы восстановления паролей в современных веб-приложениях

Question

Мы работаем над веб-приложением, в котором нам необходимо реализовать традиционные функции веб-приложений для поиска пароля В соответствии с тенденциями есть подходы, как ..

1. Отправка ссылки для сброса пароля на электронную почту пользователя.
2. Задание секретного вопроса пользователю для восстановления пароля.
3. Сброс существующего пароля, создание нового пароля и отправка его пользователю. Это также может заставить пользователя изменить пароль при следующем входе в систему.

Есть ли у нас нетрадиционный метод для реализации механизма поиска пароля? Какие еще подходы вы использовали для этого?

Спасибо.

Answer 1

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

Отправка по электронной почте ссылки для сброса пароля является предпочтительным подходом по ряду причин:

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

• Проблемы безопасности - Это самый важный фактор с технической точки зрения. Здесь есть различные проблемы, которые вы должны взвесить. Скомпрометированная учетная запись электронной почты означает, что хакер может получить доступ ко всем службам пользователей, которые позволяют отправлять ссылку для сброса пароля по электронной почте. Вы можете согласиться на золотую середину, которая заключается в отправке пользователю по электронной почте ссылки для сброса пароля, которая, в свою очередь, задает пользователю вопрос с подсказкой пароля, после чего он позволяет ему сбросить свой пароль. Опять же, вы никогда не должны раскрывать пароль пользователя на любом носителе. На самом деле, если у вас есть возможность показать им их пароль, ваша система уже небезопасна, поскольку это означает, что вы не храните их, используя безопасный хеш, такой как SHA-1, и разработчик в вашей компании может получить пароль каждого.

• Удобство использования - это самый большой фактор с точки зрения пользователя. Отправка по электронной почте ссылки для сброса пароля требует, чтобы пользователь пошел и проверил свой адрес электронной почты, что может означать, что время выполнения задачи может составить до 2 или даже 3 минут. Тем не менее, я думаю, что это не имеет большого значения. Большинство пользователей, кажется, не возражают против этого, потому что они чувствуют, что виноваты, и это мера безопасности в их интересах. Я только предполагаю из личного опыта, и пользователи в целом могут чувствовать себя по-другому. Я бы поставил безопасность как более высокий приоритет, чем пользовательский опыт, потому что пользователям редко, если когда-либо понадобится восстановить свои пароли (пользователь не вошел в систему в течение длительного времени и забыл свой пароль; пользователь сохранил свой пароль в браузере, который был переустановлен некоторые другие крайние случаи).

Answer 2

Другие варианты, которые я видел на практике, включают:

• разрешение второго пароля, когда что-то идет не так - что-то вроде Super-PIN, используемого с мобильными телефонами.
• создание файлового токена (обычно ключа PGP), который пользователь будет загружать при создании учетной записи и сохранять его на USB-накопителе, или архивировать его для дальнейшего использования. При возникновении проблемы пользователь загружает токен, тем самым доказывая, что он является «владельцем» учетной записи, и приложение, которое позволит пользователю сменить пароль. Это может быть постоянный токен или файл с несколькими токенами (аналогично TAN онлайн-банкинга) - каждый раз, когда токен используется, он также становится недействительным.

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

Answer 3

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

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

Относительно метода секретного вопроса: чаще всего ответ на секретный вопрос не так секретен, как хотелось бы. В интересах наших пользователей было бы блокировать этот метод «взлома аккаунта».

Answer 4

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

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

Answer 5

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