Сброс пароля: повторные письма и одноразовая ссылка

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

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

Разделите запрос, письмо и разрешение

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

Рекомендации OWASP Forgot Password отдельно предусматривают одноразовое использование и ограниченный срок действия токенов, их безопасное создание и хранение. Приёмка внешнего сценария не заменяет проверку реализации этих свойств. Но владелец может заранее потребовать объяснимые состояния: ссылка ещё пригодна, уже использована, истекла либо стала недействительной по предусмотренной политике.

Не объединяйте в одну кнопку два разных обещания: «запрос принят» и «письмо доставлено». Сервис может принять запрос, а отправка требует отдельной обработки. При этом ответ публичной формы не должен раскрывать наличие аккаунта; OWASP рекомендует согласованное поведение для существующих и несуществующих записей. Операционный статус отправки администратор проверяет в предусмотренном закрытом журнале.

Согласуйте политику повторного запроса

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

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

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

Проверяйте порядок создания, а не порядок писем

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

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

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

Повторное открытие и повторное использование различаются

Человек может открыть форму, закрыть вкладку и вернуться. Отдельно определите, в какой момент разрешение считается использованным. В описанной модели критическое событие — успешное завершение предусмотренной смены, а не просто показ картинки формы. Конкретный безопасный поток должен спроектировать разработчик; наличие страницы не является доказательством, что изменение уже выполнено.

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

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

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

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

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

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

Истечение срока и состояние страницы проверяются раздельно

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

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

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

После смены остаётся вопрос активных сессий

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

Если восстановление связано с подозрением на компрометацию, нужен более широкий процесс проверки аккаунта. Один пароль не объясняет состояние второго фактора, контактных каналов и уже выданных разрешений. Для отдельных проблем оставшихся доступов есть разбор сессий и токенов после отключения пользователя. Его нельзя заменить одним тестом почтовой ссылки.

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