Эффективные методы для извлечения пароля в современных веб-приложениях
Для меня, помогите мне, если все просто: когда вы работаете из Android Studio, вы пишете свой ключ API Google в файле google_maps_api.xml, но Android Studio показывает вам только файл ключа для (отладочной) версии в Диспетчере проектов. Вам также необходимо поместить свой ключ в файл
\ app \ src \ release \ res \ values \ google_maps_api.xml
(например, вы помещаете свой ключ в
\ app \ src \ debug \ res \ values \ google_maps_api.xml
)
4 ответа
Это зависит от желаемого уровня безопасности, затрат на поддержку и проблем с удобством использования.
Отправка ссылки для сброса пароля по электронной почте является предпочтительным подходом по ряду причин:
Затраты на поддержку - это самый важный фактор с точки зрения бизнеса. Пользователи часто забывают даже подсказки для пароля, используют поддельный почтовый адрес или забывают свое имя пользователя. Все это законные проблемы, по которым вы можете получить запросы в службу поддержки. Это, в свою очередь, создает другую проблему: вы должны установить легитимность пользователя, спросив его о недавних действиях в учетной записи, а о том, что нет. Если вы не обеспечите такой уровень поддержки, многие начинающие пользователи будут разочарованы. Отправка ссылки для сброса пароля по электронной почте смягчает эти проблемы, потому что у пользователей обычно есть один или два адреса электронной почты, и они могут легко восстановить свое имя пользователя / пароль, указав свой адрес электронной почты.
Проблемы безопасности - Это самый большой фактор с технической точки зрения перспектива. Здесь есть различные проблемы, которые вы должны взвесить. Взломанная учетная запись электронной почты означает, что хакер может получить доступ ко всем службам пользователей, которые позволяют отправлять ссылку для сброса пароля по электронной почте. Вы можете согласиться на золотую середину, которая заключается в отправке пользователю ссылки для сброса пароля по электронной почте, который, в свою очередь, задает пользователю вопрос с подсказкой пароля, после чего он позволяет им сбросить свой пароль. Опять же, вы никогда не должны раскрывать пароль пользователя на каком-либо носителе. По факту, если у вас есть возможность показать им их пароли, ваша система уже небезопасна, потому что это означает, что вы не храните их с помощью безопасного хэша, такого как SHA-1, и разработчик в вашей компании может узнать пароль каждого.
Удобство использования - Это самый важный фактор с точки зрения пользователя. Отправка ссылки для сброса пароля по электронной почте требует, чтобы пользователь пошел и проверил свой адрес электронной почты, что может означать, что время для выполнения задачи может достигать 2 или даже 3 минут. Однако я думаю, что это не имеет большого значения. Большинство пользователей, похоже, не возражают против этого, потому что считают, что они виноваты, и это мера безопасности в их интересах. Я только предполагаю, исходя из личного опыта, и пользователи в целом могут думать иначе. Я бы поставил безопасность как более высокий приоритет, чем взаимодействие с пользователем, потому что пользователям редко, если вообще когда-либо понадобится, извлекать свои пароли (пользователь не входил в систему в течение длительного времени и забыл свой пароль; пользователь сохранил свой пароль в браузере, который был переустановлен и некоторые другие крайние случаи).
На мой взгляд, лучше всего отправить ссылку для сброса пароля на электронную почту пользователя. путь. Это то, как Digg делает это, и так делаю я.
Но в этом методе мы должны полагаться на то, что пользователь сможет получить доступ к своей электронной почте.
Что касается метода секретного вопроса: чаще, чем нет. , ответ на секретный вопрос не такой секретный, как хотелось бы. В интересах наших пользователей заблокировать этот метод "взлома аккаунта".
Веб-сайт и его администраторы не должны знать пароль своих пользователей в виде открытого текста. Должен быть только односторонний хэш пароля, сохраненный для сравнения при аутентификации. Поэтому отправка пароля в открытом виде не должна быть вариантом.
Лично мне нравится ссылка для сброса пароля, отправляемая пользователю. Однако не забудьте истечь эту ссылку. Кроме того, уведомляйте пользователя по электронной почте о попытках сброса пароля (может быть тем же адресом электронной почты, что и ссылка для сброса), а также после успешного сброса.
Другие варианты, которые я видел на практике, включают:
- разрешение ввода второго пароля, когда что-то идет не так - что-то вроде суперпин-кода, используемого в сотовых телефонах.
- создание токена файла (обычно ключа PGP), который пользователь загрузит при создании учетной записи и сохранит на USB-накопителе или заархивирует для дальнейшего использования. Когда возникает проблема, пользователь загружает токен, тем самым доказывая, что он является «владельцем» учетной записи, а приложение позволяет пользователю изменить пароль. Это может быть постоянный токен или файл с несколькими токенами (аналогично TAN онлайн-банкинга) - каждый раз, когда используется токен, он также становится недействительным.
Вышеупомянутые методы не так просто реализовать, но они довольно удобны для пользователя (поскольку в них нет ничего нового и они используются в повседневных ситуациях).