Дизайн письма для сброса пароля: лучшие практики

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

Перейти к разделу

• Каковы цели писем для сброса пароля?
• Лучшие практики писем для сброса пароля
• Как убедиться, что ваши письма для сброса пароля безопасны
• 3 распространённые ошибки (и как их избежать)

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

•   Что, если срок действия ссылки истёк?
•   Что, если у пользователя возникают проблемы с вводом нового пароля?
•   Что, если он использует мобильное устройство?
•   И что, если он вообще не запрашивал сброс пароля?

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

1. Если запрос был инициирован пользователем, помогите ему восстановить доступ к своему аккаунту

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

Стоит отметить, что, если пользователи могут напрямую ответить на это письмо, сотрудник службы поддержки получит доступ к исходному URL для сброса пароля. Хочется надеяться, что ваша команда поддержки достаточно надёжна и не станет злоупотреблять этим, но этот момент важно учитывать. Если безопасность критически важна для вашего приложения, адрес отправителя без возможности ответа (no-reply) может быть более подходящим вариантом.

2. Если пользователь не инициировал запрос (или не уверен, что инициировал), помогите ему понять, что это означает и стоит ли беспокоиться

Поскольку программное обеспечение используется во всё большем количестве сфер жизни, сегодня всё чаще можно получить уведомление о сбросе пароля, не запрашивая его. Это может произойти из-за простой опечатки или потому, что кто-то действительно пытается получить доступ к чужому аккаунту.
Получение таких писем может сбивать с толку и даже пугать. Хорошо продуманный процесс сброса пароля (и соответствующее письмо) должен успокаивать пользователя и показывать, какие действия он может предпринять для решения проблемы.
В системах с повышенными требованиями к безопасности можно даже предусмотреть возможность одним кликом автоматически аннулировать или немедленно сделать недействительной ссылку для сброса пароля, если получатель не инициировал запрос. Также полезным может быть вторичное действие вроде «Я не делал этот запрос».

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

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

1. Понятная и уместная тема письма и имя отправителя
2. Ссылка для сброса пароля
3. Информация о сроке действия ссылки
4. Способы связи со службой поддержки
5. Кто запросил сброс (IP-адрес? User Agent?)
6. Письмо «Адрес не найден»

1. Уместная и легко читаемая тема письма и имя отправителя

Когда человеку нужно сбросить пароль, с большой вероятностью он сразу же направится в свой почтовый ящик после отправки запроса. Хотя тема письма и имя отправителя не являются самыми критичными элементами, именно их получатель видит в первую очередь. Чёткое имя отправителя и понятная тема помогают быстро распознать нужное письмо и перейти к действию.

2. Ссылка для сброса пароля

В большинстве случаев ссылка для сброса пароля — самый важный элемент письма. Она должна быть заметной и удобной для клика. Поскольку URL неизбежно будет громоздким из-за токена с ограниченным сроком действия, лучше, чтобы ссылка была указана в атрибуте HREF, а не вставлена напрямую в тело письма.

3. Информация о сроке действия

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

4. Как связаться со службой поддержки

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

5. Кто запросил сброс? (IP-адрес? User Agent?)

Ещё одной функцией безопасности является предоставление получателю контекста о том, кто (или что) инициировал запрос. В зависимости от технической подкованности вашей аудитории, это может быть просто информация об используемой операционной системе или браузере, либо более детальные данные, например IP-адрес.
Альтернативно можно использовать сервис для определения местоположения по IP-адресу, чтобы приблизительно определить, откуда был сделан запрос. Хотя это не всегда будет полезно для всех пользователей, такая информация может стать отличным инструментом для повышения доверия к продукту у подходящей аудитории.

6. Письмо «Адрес не найден»

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

Проблема со сбросом пароля заключается в том, чтобы найти правильный баланс между безопасностью и удобством. Необходимо предоставить пользователям достаточно информации, чтобы они понимали, что происходит при запросе сброса пароля, но при этом нельзя раскрывать слишком много, иначе это может сыграть на руку злоумышленникам.
В идеале вы никогда не должны прямо подтверждать или отрицать существование аккаунта с указанным адресом электронной почты или именем пользователя.
Иногда можно столкнуться с сообщением об ошибке вроде: «Мы не смогли найти пользователя с этим адресом электронной почты». Если использовать такой подход, то отсутствие этого сообщения косвенно подтверждает существование аккаунта.
Однако нельзя просто оставить пользователя в неведении. Что если у него есть аккаунт, но он зарегистрирован с другим адресом? Если не дать пользователю понять, удалось ли найти его адрес, возникает проблема удобства использования. К счастью, решение простое.
Всегда отправляйте письмо на указанный адрес электронной почты.
Ваше подтверждающее сообщение, отображаемое на веб-странице, будет просто следующим: «На адрес (указанный адрес электронной почты) отправлено письмо с дальнейшими инструкциями». Однако содержание этого письма изменяется в зависимости от того, существует ли аккаунт с этим адресом:

•   Если пользователь существует, вы отправляете стандартное письмо для сброса пароля с URL и инструкциями.
•   Если пользователя нет, вы отправляете другое письмо, объясняющее, что аккаунт не найден, и предлагаете попробовать другой адрес электронной почты.

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

1. Отправка паролей в открытом виде по электронной почте

Отправка паролей в открытом виде связана с управлением паролями, но эта проблема встречается достаточно часто и является серьёзной, поэтому её стоит обсудить здесь.
Если письмо для сброса пароля когда-либо содержит сам пароль, это значит, что система управления паролями работает неправильно. Точка. Исправление этой проблемы, скорее всего, потребует изменений в инженерной части, но само наличие пароля в письме должно быть огромным тревожным сигналом.
Вместо паролей письма должны отправлять только временные и безопасные URL-ссылки.

2. Случайно выглядеть как фишинговое письмо

Письма для сброса пароля — это как раз классический пример фишинговых писем. Иногда фишинговые письма отлично подражают бренду отправителя, а иногда они плохо оформлены и неаккуратны.
Если вы отправляете письмо для сброса пароля с небрежным текстом и неудобной ссылкой с случайно сгенерированным токеном, людям будет сложно понять, можно ли доверять письму.
Конечно, если пользователь сам запрашивал сброс пароля, он, скорее всего, не будет волноваться, но это происходит не всегда. По возможности добавляйте релевантную информацию, чтобы ваши письма выделялись на фоне фишинговых попыток.
Если вы знаете, что в вашей отрасли распространены фишинговые атаки, убедитесь, что у вас настроена политика DMARC. Это поможет решить проблему и даст вашим клиентам уверенность, что письма от вас действительно исходят от вашей компании.

3. Медленная отправка или плохая доставляемость

Ещё одной проблемой, которая может возникнуть с письмами для сброса пароля, является медленная отправка. Как правило, если письмо идёт в почтовый ящик больше 20 секунд, это считается медленным. Если доставка занимает более минуты, ваши клиенты могут уйти (и возможно не вернутся) или обратятся в службу поддержки. Оба исхода вредят вашему бизнесу.
Поскольку медленная отправка влияет на вашу репутацию и создаёт дополнительную нагрузку для команды, важно выбрать почтового провайдера, который может быстро и надёжно доставлять ваши письма для сброса пароля. На первый взгляд кажется, что почтовые сервисы предоставляют стандартную услугу, но когда копнуть глубже в показатели производительности, надёжности и доставляемости, оказывается, что это далеко не всегда так.
В HaskiMail мы публикуем наши скорости доставки транзакционных писем к основным почтовым провайдерам прямо на странице статуса. Быстрая доставка писем в почтовый ящик — ключевой элемент хорошей доставляемости.
В некоторых случаях можно мириться с медленной отправкой, но когда люди запрашивают сброс пароля, они ожидают, что письмо придёт почти мгновенно. Поэтому внимательно следите за временем доставки и обращениями в поддержку по вопросам сброса пароля, поскольку это один из первых признаков проблем — и возможно, ваш провайдер не выполняет свои обязательства.