У нашего заказчика есть интернет-портал и пользователи, данные которых заведены в домене. Доступ в личный кабинет — по паролю, а где пароль, там и людская забывчивость.
У нас уже была страница смены пароля, но механизм работы был не оптимальным. Вот как всё происходило. Пользователь оставлял заявку в домене на смену пароля. В ответ система, в свою очередь, оставляла заявку, которую администратор обрабатывал вручную. Он генерировал пароль в домене, после чего приписывал его в заявке. Пользователю приходило email-уведомление: “Ваш пароль изменён на такой”.
Нас смущали три момента:
- Sharepoint, от которого мы уходим в тех местах, где он не нужен.
- Потребность в участии администратора. Нам не хотелось отвлекать квалифицированного специалиста на подобные рутинные и частые операции.
- Мы присылали пароль прямо в письме, что не очень-то безопасно. Такой пароль можно прочесть с экрана. Появляется много вариантов, как он может утечь.
И ещё был психологический момент: система создавала такие сложные пароли, что их было сложновато запомнить, оставалось только где-то записать.Тоже небезопасно. Зато такой пароль очень просто забыть. Можем предположить, что это обстоятельство тоже влияло на количество заявок на смену пароля.
Итак, стало понятно, что механику смены пароля пора изменить.
Кейсы такого типа требуют баланса между информативностью и умеренностью. Пользователя не стоит перегружать деталями и абзацами текста. В то же время написать два Input и поставить одну кнопку тоже неправильно. Поэтому мы привлекли к работе дизайнера и копирайтера. Мы прошли этот путь и составили 10 подсказок, как сделать это оптимальным образом и на фронтенде, и на бэкенде.
1. Оформите письмо и страницу со сменой пароля по UI kit
Сделайте письмо и страницу со сменой пароля по 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 есть здесь.
Так мы добились своих целей: автоматизировали смену пароля, освободив рабочее время администратора для более важных задач, и сделали процесс максимально безопасным. Надеемся, этот чеклист поможет вам проверить себя в подобной задаче.
