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

Question

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

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

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

Спасибо.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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