После переноса сайта пароль администратора может приниматься, а одноразовый код — отклоняться. Это не повод отключать двухфакторную защиту для всех. Нужно понять, потерян ли секрет TOTP, расходятся ли часы или новая среда неправильно обрабатывает сессию и защищенные данные.

Начните с синхронизации времени и сравнения ключей шифрования между средами. Затем проверьте cookies, HTTPS, reverse proxy и сохранность таблиц 2FA. Восстанавливайте доступ через заранее предусмотренный recovery-процесс с журналом действий.

Что проверить в первую очередь

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

  • Сравните время сервера с точным источником и проверьте состояние NTP.
  • Убедитесь, что при переносе не изменился application key, которым зашифрованы TOTP-секреты.
  • Проверьте домен, Secure/SameSite cookies, HTTPS и заголовки от reverse proxy.
  • Найдите штатные recovery-коды или резервного администратора, не отключая 2FA глобально.

Почему возникает проблема

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

  • Часы новой системы расходятся настолько, что текущий TOTP попадает за допустимое окно.
  • Секреты 2FA скопированы, но не расшифровываются новым ключом приложения.
  • Таблица, поле или миграция с TOTP-секретами не попали в резервную копию.
  • Сессия теряется между вводом пароля и кода из-за домена cookie, HTTPS или балансировщика.
  • Прокси передает неверную схему, и приложение считает безопасный запрос HTTP-запросом.

Пошаговая диагностика

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

  • Сравните UTC-время сервера и телефона, не меняя окно TOTP до выяснения причины.
  • Проверьте наличие и формат зашифрованного секрета у одного тестового администратора.
  • Проследите запрос входа в Network: session cookie должна сохраняться и отправляться на шаг проверки кода.
  • Снимите серверные логи авторизации без записи самого одноразового кода и секрета.
  • Проверьте trusted proxy, forwarded headers и генерацию HTTPS-адресов.

Безопасное восстановление административного доступа

Аварийный вход должен подтверждать личность администратора и оставлять аудит. Изменение записи напрямую допустимо только как контролируемая процедура с резервной копией.

  • Сначала используйте одноразовый recovery-код или второго администратора с действующей 2FA.
  • Если секрет потерян, сбросьте 2FA только для конкретной учетной записи после дополнительной проверки владельца.
  • Сделайте резервную копию строки пользователя и зафиксируйте кто, когда и почему выполнил сброс.
  • После входа немедленно зарегистрируйте новый секрет и сохраните новые recovery-коды.
  • Проверьте остальные административные аккаунты и отзовите старые активные сессии.

Как исправить проблему

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

  • Включите синхронизацию NTP и исправьте системный часовой пояс без ручной подгонки часов.
  • Верните корректный application key из защищенного секрета среды либо штатно перевыпустите 2FA.
  • Исправьте cookie domain, Secure, SameSite и настройки trusted proxies.
  • Восстановите пропущенные миграции и данные из проверенной резервной копии.
  • Добавьте отдельную проверенную команду точечного сброса 2FA с аудитом и ограниченным доступом.

Безопасный порядок внедрения

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

Как проверить результат

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

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

Типичные ошибки при исправлении

  • Отключать middleware 2FA для всего административного раздела.
  • Увеличивать допустимое окно кодов настолько, что ослабляется защита, вместо исправления часов.
  • Логировать TOTP-секреты, коды или полный набор cookies.
  • Генерировать новый application key без понимания, какие еще данные им зашифрованы.

Как предотвратить повторение

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

  • Контролируйте NTP и расхождение времени как системную метрику.
  • Храните application key в резервируемом менеджере секретов отдельно от кода.
  • Тестируйте recovery-процесс и наличие второго администратора до миграции.
  • Включайте проверку 2FA, cookies и proxy-заголовков в чек-лист переноса.

Что подготовить для разбора

  • Краткое описание ожидаемого и фактического поведения без паролей, токенов и персональных данных.
  • Точное время и последовательность действий, после которых появляется проблема.
  • Версии приложения, окружения и зависимостей, а также перечень последних изменений.
  • Фрагменты журналов с контекстом до и после ошибки; секреты в них необходимо скрыть.
  • Описание уже выполненных проверок и способ безопасно повторить проблему.

Частые вопросы

Можно ли увеличить окно TOTP?

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

Что делать, если ключ шифрования потерян?

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

Когда нужна помощь специалиста

Если после переноса администраторы потеряли доступ, я могу проверить время, ключи, сессии и proxy-настройки, безопасно восстановить конкретные учетные записи и оформить рабочую процедуру аварийного доступа без глобального отключения 2FA.