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

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

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

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

Спасибо.

Ответ 1

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

Отправка пароля reset ссылка предпочтительнее по нескольким причинам:

Стоимость поддержки. Это самый большой фактор с точки зрения бизнеса. Пользователи часто забывают даже свои подсказки пароля или используют фальшивый почтовый адрес или забывают свое имя пользователя. Все это законные проблемы, для которых вы можете получить запросы поддержки. Это, в свою очередь, создает еще одну проблему, вы должны установить легитимность пользователя, спросив их о недавней активности аккаунта, а что нет. Если вы не обеспечите такой уровень поддержки, многие начинающие пользователи будут разочарованы. Отправка по электронной почте пароля reset связывает эти проблемы, поскольку пользователи обычно имеют один или два адреса электронной почты, и они могут легко восстановить свое имя пользователя/пароль, указав свой адрес электронной почты.
Проблемы безопасности. Это самый важный фактор с технической точки зрения. Здесь есть различные проблемы, которые вы должны взвесить. Скомпрометированная учетная запись электронной почты означает, что хакер может перейти к доступу ко всем службам пользователей, которые позволяют отправить ссылку на пароль reset. Вы можете рассчитывать на средний уровень, который заключается в том, чтобы отправить по электронной почте пароль reset пользователю, который, в свою очередь, задает пользователю вопрос с подсказкой пароля, после которого он позволяет им reset их пароль. Опять же, вы никогда не должны выставлять пароль пользователя на любом носителе. Фактически, если у вас есть возможность показать им свой пароль, ваша система уже небезопасна, потому что подразумевает, что вы не храните их с помощью безопасного хэша, такого как SHA-1, и разработчик в вашей компании может получить пароль каждого пользователя.
Юзабилити. Это самый большой фактор с точки зрения пользователя. Отправка по электронной почте пароля reset требует от пользователя перехода и проверки их адреса электронной почты, что может означать, что время для выполнения задачи может увеличиться до 2 или даже 3 минут. Однако я бы подумал, что это не имеет большого значения. Большинство пользователей, похоже, не возражают против этого, потому что считают, что они виноваты, и это мера безопасности в их интересах. Я только выдвигаю гипотезу из личного опыта, и пользователи в целом могут чувствовать себя по-другому. Я бы поставил безопасность в качестве более высокого приоритета, чем пользовательский опыт, потому что пользователям редко приходится когда-либо извлекать свои пароли (пользователь долго не заходил в систему и забыл пароль, пользователь сохранил свой пароль в браузере, который был переустановлен и некоторые другие случаи ребер).

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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