Руководства по безопасности
Ошибки в сбросе пароля: 5 способов захватить аккаунт при надёжном входе и как их исправить
Длинный пароль и многофакторная аутентификация не помогут, если функция «Забыли пароль?» слабая: атакующий захватит аккаунт через сброс, а не через вход. Пять способов, которыми ломаются процессы сброса, требования, которые OWASP называет прямо, и как решать то, что руководство намеренно оставляет вам.
Ссылка «Забыли пароль?» ведёт к механизму, который позволяет человеку, не знающему пароль, задать новый. Значит, это путь аутентификации — и обычно самый слабый в сервисе.
Почему одного усиления входа недостаточно
Обычный путь: вход
Длинные пароли · многофакторная аутентификация · ограничение частоты · обнаружение перебора
─────── тот же аккаунт ───────
Отдельный путь: сброс пароля
Работает, если пришло письмо · часто без второго фактора · надёжность токена не видна
Сброс делают как удобство для пользователей, поэтому его часто не проектируют и не проверяют так же строго, как аутентификацию. Но по сути он передаёт управление аккаунтом тому, кто не знает пароля. Ему место в той же категории, что и входу.
Это совпадает с тем, что мы увидели, когда разобрали японские инциденты 2026 года по способу проникновения (на английском): вход с действительными учётными данными встречается чаще, чем эксплуатация уязвимости. Сброс пароля — это место, где сервис сам выдаёт такие учётные данные по своей официальной процедуре.
Пять видов ошибок
- 1. Угадываемые токены
- Последовательные значения, метки времени, короткие строки или некриптографическая случайность. Чужой сброс можно завершить, угадав токен или перебрав варианты
- 2. Токены, которые не умирают
- Нет срока действия, токен действует после использования, его можно применить повторно. Однажды выданная ссылка работает бесконечно
- 3. Ссылки, которые остаются в почте
- Кто читает почтовый ящик, тот может прочитать и ссылку для сброса. Правила пересылки, общие ящики, почта уволившегося коллеги — письма видит больше людей, чем вы думаете
- 4. Адрес задаётся извне
- Если собирать URL для сброса из заголовка
Hostзапроса, значение извне может оказаться ссылкой в вашем письме (внедрение через заголовок Host) - 5. Ответы, выдающие аккаунт
- Полезное сообщение «не зарегистрирован» или разница во времени ответа превращают форму в способ проверить извне, у кого есть аккаунт (перебор пользователей)
CWE-640 «Weak Password Recovery Mechanism for Forgotten Password» (слабый механизм восстановления забытого пароля) — так называется этот класс ошибок. Его определение: продукт содержит механизм, позволяющий пользователям восстановить или сменить пароль, не зная исходного, но этот механизм слабый. Обратите внимание, о чём здесь речь: проблема не в наличии функции, а в том, что она слабее аутентификации, которую может заменить.
Не делайте контрольные вопросы единственным способом
Позиция OWASP по контрольным вопросам: их не следует использовать как единственный механизм сброса пароля, потому что ответы часто легко угадать или узнать, хотя в сочетании с другими методами они могут дать дополнительный уровень. Девичья фамилия матери — не секрет в эпоху соцсетей и открытых реестров.
Что требует руководство и что оставляет вам
Здесь реализация обычно и спотыкается. Разделяйте эти две вещи.
Прямо указано OWASP
・Генерировать токены криптографически стойким генератором случайных чисел
・Делать их достаточно длинными для защиты от перебора
・Аннулировать после использования
・Возвращать одинаковое сообщение для существующих и несуществующих аккаунтов
・Держать одинаковым и время ответа, чтобы не допустить перебора
・Использовать ограничение частоты, CAPTCHA или похожие меры против автоматических отправок
・Автоматически завершать существующие сессии или спрашивать пользователя, завершить ли их
・Сообщать пользователю по почте, что пароль сброшен, и не указывать пароль в письме
・Не полагаться на заголовок Host при сборке URL для сброса (задать жёстко или проверять по списку доверенных доменов)
・Использовать в URL HTTPS
Числа, которые руководство не задаёт (решаете вы)
・Конкретная длина токена — сказано только «достаточно длинный»
・Срок действия — аннулирование после использования обязательно, а конкретный срок не указан
Не читайте отсутствие числа как «это можно не решать». Решить нужно, с обоснованием, и записать.
Наши практические значения: не менее 128 бит случайности в URL-безопасной кодировке; срок действия в десятки минут; аннулирование после использования; аннулирование старых токенов при выдаче нового для того же аккаунта. Числа важны меньше, чем три свойства: нельзя угадать, нельзя использовать повторно, не живёт вечно.
Порядок внедрения
Сделайте токен неугадываемым (главное)
Генерируйте его из криптографического источника случайности и кодируйте в URL-безопасном виде. Не используйте обычную функцию случайных чисел: «выглядит случайным» и «нельзя предсказать» — разные свойства. Храните хеш токена, а не сам токен, чтобы прочитанная база данных не давала сразу рабочих токенов (то же рассуждение, что и в статье хранение паролей: хеширование и соль).
Задайте срок жизни и разрешите одно использование
Аннулируйте токен после использования и по истечении времени. При выдаче нового токена для того же аккаунта аннулируйте старые — если забыть об этом, вы вернётесь к ошибке второго вида.
Никогда не собирайте URL из внешних данных
Формируйте ссылку для сброса из настроек или проверяйте по списку доверенных доменов. Не переносите заголовок запроса в письмо. OWASP называет это прямо.
Сделайте ответы одинаковыми и ограничьте частоту
Возвращайте одинаковый текст и одинаковое время ответа в обоих случаях, а письмо отправляйте, только если аккаунт существует. Добавьте ограничение частоты по аккаунту или CAPTCHA против автоматических отправок. Пользователям это не мешает, а снаружи два случая неразличимы.
Доведите дело до конца после сброса
После завершения сброса завершите существующие сессии — если аккаунт уже захвачен, только так можно выгнать атакующего — и отправьте уведомление о сбросе пароля (без самого пароля). Где возможно, требуйте второй фактор и при сбросе, чтобы сброс не стал обходом многофакторной аутентификации.
На самом деле сброс зависит от почтового ящика
Даже если сделать всё перечисленное, безопасность сброса держится на том, что письмо может получить только владелец аккаунта. Если почтовый аккаунт взломан, хорошо сделанный сброс передаст аккаунт атакующему надёжнее, чем небрежный. Поэтому приоритет для пользователя тот же: защитите почтовый аккаунт сильнее всего — надёжным уникальным паролем и многофакторной аутентификацией, в идеале ключом доступа (passkey). Это же путь, по которому утечка у провайдера доходит до вас (что делать, если взломали ваш хостинг-провайдер).
Как это выглядит со стороны пользователя
- Письмо о сбросе, которое вы не запрашивали, — уведомление о том, что кто-то пытался. Не переходите по ссылке — зайдите в сервис сами и проверьте (фишинг выглядит точно так же).
- Если после сброса вас разлогинило на других устройствах, это признак правильной реализации. Сервис, который оставляет другие сессии активными после сброса, не даёт вам способа отключить постороннего.
- Если при сбросе не спросили второй фактор, многофакторную аутентификацию в этом сервисе, возможно, можно обойти через сброс. Стоит один раз проверить на важных аккаунтах.
- Отказ от повторного использования паролей лучше всего поручить менеджеру паролей.
Взгляд этого сайта: стройте сброс как аутентификацию, а не как удобство
Сброс пароля становится слабым не потому, что это технически сложно, а потому, что его относят не к той категории. Вход тщательно делают специалисты по аутентификации, а «Забыли пароль?» делают на скорую руку как путь для поддержки. Эта разница в отношении и есть слабость. Наша позиция проста: любая операция, передающая управление аккаунтом, — это функция аутентификации: сброс, смена адреса почты, повторная привязка второго фактора, ручное восстановление сотрудником поддержки. Надёжность определяется самым слабым путём, а не самым сильным. Выпишите все пути к аккаунту в своём сервисе — обычно их больше, чем кажется.
Источники (первичные)
- OWASP Cheat Sheet Series, «Forgot Password Cheat Sheet» — cheatsheetseries.owasp.org (все требования, перечисленные выше как «прямо указано», взяты из этого документа; длина токена и срок действия в нём не указаны)
- MITRE, CWE-640 «Weak Password Recovery Mechanism for Forgotten Password» — cwe.mitre.org
Что прочитать дальше
- Защита: как выбрать менеджер паролей и пользоваться им / хранение паролей: хеширование и соль
- Термины: что такое двухфакторная аутентификация / что такое ключ доступа (passkey) / что такое фишинг
- Защита от злоупотреблений: ограничение частоты запросов и защита от злоупотреблений (где должно стоять ограничение частоты для сброса)
- Тенденция: в 2026 году атакующие чаще приходили с учётными данными, чем с эксплойтами (на английском)
FAQ
QЕсли включена многофакторная аутентификация, важен ли слабый сброс пароля?
Да. Многие реализации не требуют второго фактора при сбросе, и тогда сброс — способ вернуть себе аккаунт в обход второго фактора. Защищать нужно не силу экрана входа, а силу каждого пути, ведущего к аккаунту. Завершайте существующие сессии после сброса и, где возможно, требуйте второй фактор и при сбросе.
QКакой длины должен быть токен сброса и сколько он должен жить?
OWASP Forgot Password Cheat Sheet требует генерировать токены криптографически стойким генератором случайных чисел, делать их достаточно длинными для защиты от перебора и аннулировать после использования — но не называет ни число символов, ни число минут. Это решаете вы. Наши практические значения по умолчанию: не менее 128 бит случайности в URL-безопасной кодировке, срок действия в десятки минут, аннулирование после использования и аннулирование старых токенов при выдаче нового для того же аккаунта. Числа важны меньше, чем три свойства: нельзя угадать, нельзя использовать повторно, не живёт вечно.
QРазве сообщение «этот адрес не зарегистрирован» — не полезная подсказка?
Полезная для ваших пользователей — и бесплатный способ для атакующего проверить, у каких адресов есть аккаунт у вас. OWASP требует одинаковое сообщение для существующих и несуществующих аккаунтов и одинаковое время ответа. Показывайте одно и то же в обоих случаях, а письмо отправляйте, только если аккаунт действительно есть: пользователям это не мешает, а снаружи разницы не видно.
QЧто могу сделать я как пользователь?
Письмо о сбросе, которое вы не запрашивали, — это уведомление о том, что кто-то пытался сбросить ваш пароль. Не переходите по ссылке: зайдите в сервис сами и проверьте, что пароль нигде больше не используется и что многофакторная аутентификация включена. И помните, от чего на самом деле зависит сброс: от вашего почтового ящика. Если кто-то читает вашу почту, он может подряд сбросить пароли многих ваших аккаунтов. Защитите почтовый аккаунт сильнее всего.