Если после успешного сброса старый пароль продолжает принимать форма входа, смена либо записалась не туда, либо авторизация читает другой источник. Отдельно нужно проверить активные сессии: они могут оставаться действительными, хотя старый пароль уже не принимается.
Проверьте вход старым и новым паролем в чистом браузере, затем сравните запись пользователя, реплики, кэш и путь обычного входа с путем восстановления.
Коротко: что сделать
- Отличить повторный вход от существующей сессии
- Проверить время password_changed_at
- Проверить единственный актуальный password_hash
- Проверить чтение с primary и replica
- Проверить SSO или внешний каталог учетных записей
Почему возникает проблема
Форма восстановления и форма входа могут использовать разные сервисы, базы или кэши. Поэтому визуально успешная смена не гарантирует смену источника проверки.
- Новый hash сохранен в профиле, а вход читает другую таблицу
- Реплика отстает после записи
- Кэш пользователя не инвалидирован
- Старый legacy-hash проверяется вторым способом
- Вход выполняется через SSO, а не локальный пароль
- Тест фактически использует сохраненную сессию
Пошаговая диагностика
Проверку лучше проводить на одном воспроизводимом примере и фиксировать результат каждого шага. Так можно быстро отделить первопричину от побочных ошибок и не менять несколько компонентов одновременно.
- Выполнить новый вход в режиме инкогнито
- Проверить ответ logout и удаление cookie
- Сверить hash до и после сброса без вывода значения
- Трассировать запрос входа до источника данных
- Проверить lag реплики
- Проверить журнал security events
Как исправить
Смена пароля должна быть одной транзакцией: запись нового hash, обновление версии учетных данных и инвалидация зависимых данных.
- Оставить один актуальный password_hash
- Читать критическое состояние после записи с primary
- Инвалидировать кэш пользователя
- Увеличить credential_version и проверить ее в сессиях
- Отозвать reset token после использования
- Явно разделить локальный пароль и SSO-вход
Как проверить результат
- Проверить старый пароль в новой сессии
- Проверить новый пароль
- Проверить повторное использование reset link
- Проверить активные устройства согласно политике
- Проверить журнал без утечки токенов
Как не допустить повторения
Операции с паролем должны иметь единый сервис и набор security-событий.
- Добавить интеграционный тест полного сброса
- Хранить время и версию смены credentials
- Не кэшировать password hash надолго
- Мониторить отставание реплик
Чего не стоит делать
- Не логировать пароль и reset token
- Не считать активную cookie доказательством работы старого пароля
- Не хранить несколько действующих хешей без миграционного правила
- Не показывать пользователю внутреннюю структуру учетной записи
Что подготовить для диагностики
- Время сброса
- ID пользователя
- Схема входа и восстановления
- Источники данных и кэш
- Политика отзыва сессий
Частые вопросы
Нужно ли завершать все сессии после смены пароля?
Это зависит от политики, но при подозрении на компрометацию безопаснее отозвать все активные сессии.
Может ли мешать реплика MySQL?
Да. Вход сразу после записи может прочитать старый hash с отстающей реплики.
Почему старый пароль работает только в одном браузере?
Вероятнее всего, браузер использует старую активную сессию, а не выполняет проверку пароля заново.
Когда стоит обратиться за помощью
Помощь нужна, если система использует SSO, несколько баз, реплики или старую схему хеширования и нельзя точно доказать, какой путь принял старые учетные данные.
Итог
Исправление требует проверить реальный повторный вход, источник hash, кэш, реплики и сессии. Провести безопасный аудит восстановления доступа можно через @rabotator_support.