Смена пароля: 10 шагов к хорошей реализации

В этой статье поделимся опытом компании True Engineering: как мы реализовали механизм смены пароля для личного кабинета интернет-портала. В процессе мы использовали и обобщили 10 best practices. Надеемся, что они пригодятся всем, кто решает ту же задачу или хочет проверить свой функционал.

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

Ранее, чтобы обновить пароль, пользователь оставлял заявку на портале, она летела к администратору, который вручную генерировал пароль и привязывал его к заявке. В результате пользователю приходило email-уведомление: «Ваш пароль изменён на такой».

Мы хотели изменить три момента:

Итак, стало понятно, что механику смены пароля пора изменить.

Кейсы такого типа требуют баланса между информативностью и умеренностью. Пользователя не стоит перегружать деталями и абзацами текста. В то же время написать два Input и поставить одну кнопку тоже неправильно. Поэтому мы привлекли к работе дизайнера и копирайтера. А по результату работы составили 10 подсказок на основе своего опыта, как сделать механику смены пароля оптимальной и на фронтенде, и на бэкенде.

1. Оформите письмо и страницу со сменой пароля по UI kit

Сделайте письмо и страницу со сменой пароля по UI kit, то есть красиво, в общем стиле сайта и хорошо локализованной. Это нужно, чтобы легче ориентироваться. Даже если человек отвлекся от процесса, то вернувшись через 10 минут, он поймёт, на каком ресурсе находится и зачем он тут.

2. Напишите понятные тексты

Поработайте над текстами, чтобы из них стало предельно понятно, что сейчас происходит и что требуется от пользователя. Желательно, чтобы тексты соответствовали редакционной политике заказчика (стиль общения) и были составлены с учётом best practices. Так получаются красивые и содержательные письма.

3. Укажите, кто и когда сбросил пароль

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

Эту информацию мы сделали посветлее, чтобы она была видна, но не мозолила глаза. А основная ссылка на смену пароля нарисована большой яркой кнопкой — пользователь её сразу видит.

4. Сделайте ссылку на смену пароля временной

Временная ссылка на смену пароля — это общемировая практика. После того, как пользователь подал заявку на смену пароля, ему нужно поменять этот пароль в определенное время: например, в течение 5 минут или 24 часов. Получается, что есть четко ограниченное временное окно, в которое кто угодно может поменять пароль пользователю. Поэтому в целях безопасности это время ограничено.

5. Не используйте сторонних библиотек на странице смены пароля

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

6. Исключите техподдержку из процесса (без крайней необходимости)

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

Проблемными заявками занимаются специалисты, которые вникают в технические причины ошибок и способны самостоятельно их исправить.

7. Сделайте техподдержке красивый UI — им будет приятно

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

8. Пишите историю ошибок

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

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

9. Дайте техподдержке возможность сменить пароль

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

10. Отслеживайте запросы и динамику

Мы настроили мониторинг при помощи Serilog. В ELK сбрасываем событие, а потом через Grafana отслеживаем четыре разновидности ситуации, когда пользователь запросил смену пароля:

a. Зеленая линия — пользователь был найден в домене,

b. Красная линия — логин пользователя не был найден в домене. Для нас второе действие — это маркер. Если этот график ползет вверх, то превышает одну попытку в сутки, это может означать, что какой-то недобросовестный товарищ пытается собрать базу.

На это мы можем оперативно отреагировать, отключив айпишник. Далее эту деятельность можно автоматизировать — например, автоматически отключать айпишник после десяти запросов. Но это не всегда работает, поскольку некоторые компании сидят в интернете с одного IP-адреса, поэтому пока просто мониторим этот график. Его постоянно просматривает служба поддержки. И если он вдруг пойдёт вверх, в моменте решим, что нам делать.

c. Зелёная линия — пользователь успешно запросил смену пароля и открыл нужную ссылку, соответственно, мы предполагаем, что всё хорошо.

d. Красная линия — пользователь не смог открыть страницу со сменой пароля. Ссылка была с несуществующим ID, устаревшая и т.д. Довольно странно предполагать, что какой-то хакер пытается перебрать уникальные идентификаторы, чтобы поймать тех, кто пытается сменить пароль. Но в принципе мы можем мониторить эти события — и если увидим, что этот график пошёл вверх, то можем разобрать события и посмотреть, что происходит. Например, может оказаться, что ID битый, от него отрезался кусок и ссылка в email вставляется некорректно.

В итоге у нас есть четыре графика и сплошное полотно событий, где можем понимать, что произошло. Все инструкции по настройке Grafana есть здесь.

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