Инвентаризация: что именно у вас сохранено

Файл с цифрами, приложение Authenticator и passkey могут выглядеть как «запасной вход», но ведут себя по-разному. Recovery code — статичный секрет для отдельной ветки входа или сброса. TOTP — короткий код, который постоянно меняется. SMS приходит на номер в конкретный момент. Passkey — криптографическая запись на устройстве или в credential manager. Apple Recovery Key — отдельная модель восстановления Apple Account.

Эти различия проще оценить после базового объяснения, как устроена двухфакторная аутентификация. Пароль подтверждает знание секрета, второй фактор — доступ к другому средству, а recovery method предназначен для аварийной ситуации. Иногда passkey удовлетворяет сразу нескольким требованиям, но это функция конкретной платформы, а не свойство любого «резервного ключа».

Статичный код не всегда одноразовый список

Google выдаёт 10 восьмизначных backup codes, GitHub — 16 recovery codes. В обеих системах один использованный элемент больше не работает, а генерация нового набора отменяет весь предыдущий список. Microsoft Account использует один 25-значный recovery code, и новый код сразу отменяет старый. Apple Recovery Key — один 28-символьный секрет с отдельными условиями. Количество нельзя запоминать как общее правило 2FA.

TOTP backup — не копия recovery-code file

Authenticator хранит исходные данные, из которых приложение создаёт меняющиеся коды. Google Authenticator может синхронизировать записи через Google Account; в режиме без аккаунта записи остаются на устройстве. Microsoft Authenticator backup зависит от платформы и типа записи: iOS backup не переносится на Android, для некоторых work/school или passwordless записей после restore требуется повторный вход. Надпись «backup complete» не доказывает восстановимость каждого токена.

Passkey — не строка для распечатки

Google указывает, что passkey может обходить второй шаг, поскольку подтверждает владение разблокированным устройством; добавление passkey не удаляет существующие recovery factors. GitHub позволяет использовать ранее добавленную passkey для возвращения доступа, причём она может удовлетворить пароль и 2FA. Но если единственная passkey находится на потерянном телефоне и нигде не синхронизирована, независимого резерва нет.

Для карты доступа записывайте тип, а не только слово «код»: `Google backup-code set`, `Apple Recovery Key`, `Microsoft recovery code`, `GitHub recovery-code file`, `TOTP backup`, `passkey на устройстве X`. Сам секрет в открытый реестр не включайте. Отдельно не смешивайте пароль и recovery secret.

Граф отказов вместо абстрактного «надёжного места»

Место хранения считается полезным не потому, что оно бумажное или цифровое, а потому что остаётся доступным после вероятной аварии. Нарисуйте цепочку: основной телефон → Authenticator → главная почта → password manager → recovery code. Если каждый элемент открывается только через предыдущий, потеря телефона закрывает всю цепь.

Минимальный практический тест выполняется без реальных кодов: представьте, что телефон исчез, SIM недоступна, а вход на новом компьютере требует 2FA. Где находится копия? Чем открыть её хранилище? Нужна ли для этого та же почта? Есть ли другой зарегистрированный фактор? Кто помогает с managed account? Ответы показывают слабое звено лучше, чем количество созданных файлов.

Password manager

GitHub прямо рекомендует secure password manager как один из вариантов. Он удобен для маркировки использованных кодов и контроля доступа. Однако recovery самого vault должен быть независимым. Проверьте emergency kit, уже авторизованные устройства и семейную или бизнес-процедуру. Статья о том, как оценить менеджер паролей как защищённое хранилище, помогает закрыть именно эту зависимость.

Бумага и внешний носитель

Бумажная копия переживает сетевой сбой, но требует физического контроля, защиты от воды, огня и посторонней камеры. Зашифрованный накопитель зависит от пароля расшифровки, совместимого устройства и исправности носителя. Не кладите рядом полностью подписанные пароль, email и recovery code: такая «удобная папка» превращает несколько факторов в один пакет.

Почта и облачная заметка

Письмо самому себе или заметка в том же аккаунте часто создают круг: код нужен, чтобы войти в почту, а почта нужна, чтобы прочитать код. Главную почту следует защитить как самостоятельный recovery channel и обеспечить ей отдельный аварийный путь. Apple отдельно не советует хранить Recovery Key только в Apple Passwords, iCloud Photos, Notes или iCloud Drive.

Четыре провайдера — четыре контрольные проверки

Google Account

Backup code используется вместо обычного второго шага, а не вместо идентификатора аккаунта. После использования конкретный восьмизначный код становится неактивным. Новый набор из 10 значений отменяет старый автоматически. Google советует не сообщать коды никому и уточняет, что запрашивает их только при входе. В Advanced Protection скачать backup codes нельзя, поэтому план строится на разрешённых там методах.

Apple Account

Recovery Key включают на trusted device и подтверждают во время настройки. Это один 28-символьный секрет, применяемый вместе с trusted phone number и Apple device по текущей процедуре Apple. Включение ключа отключает стандартный account recovery. Если утрачен пароль, trusted device и сам ключ, доступ может быть потерян навсегда. Решение требует осознанной ответственности, а не механического включения.

Microsoft Account

Один 25-значный recovery code помогает в сценарии забытого пароля или компрометации. Microsoft не позволяет повторно скачать уже созданный код: пока доступ есть, можно только выпустить новый, немедленно отменив предыдущий. Официальная рекомендация — распечатать его и не хранить на устройстве, используемом для обычного входа.

GitHub

Каждый элемент из 16-code file применяется один раз. Новый список отменяет старый. GitHub также предлагает настроить два или больше authentication methods и документирует другие recovery factors: passkey, security key, verified device, а при определённых условиях SSH key или personal access token. Наличие метода в старой инструкции не означает, что он доступен сейчас именно вашему аккаунту.

Интерактивный аварийный комплект

Модуль выбирает ближайшее действие по самому строгому признаку. Он ничего не сохраняет и не проверяет ваш секрет. Не вводите код, пароль, email или QR seed — отметьте только состояние.

Логика остаётся видимой без JavaScript. Managed account всегда передаётся администратору; закрытый доступ — официальному recovery process; раскрытый секрет — на ротацию; отсутствующая или зависимая копия — на создание независимого резерва. Затем проверяются другой фактор и актуальность карты.

Смена телефона без потери факторов

Миграцию начинайте на старом рабочем устройстве, не после его очистки или продажи. Составьте список сервисов, где используется TOTP, push approval, passkey или привязка к номеру. Для каждого отметьте, переносится ли запись через backup, требуется ли re-enrollment и есть ли recovery code. Не полагайтесь на то, что новая иконка Authenticator автоматически означает готовый вход.

1. Проверьте независимый recovery method. Копия должна открываться без старого телефона, но не должна быть опубликована или отправлена в чат.
2. Настройте новый фактор по официальной инструкции. Для некоторых сервисов нужно отсканировать новый QR, подтвердить старым фактором или войти повторно.
3. Проверьте контрольный результат. В security settings видно новое устройство или метод; резервная копия доступна; старый фактор пока остаётся активным.
4. Только затем удалите старое. Отзовите привязку, завершите сеансы и очистите устройство после проверки нового пути.
5. Обновите карту. Дата, тип фактора и место recovery copy должны соответствовать текущей конфигурации.

Microsoft Authenticator отдельно предупреждает о границе между iOS и Android. Для personal TOTP entries возможен более полный restore, а work/school account может восстановиться только как имя и потребовать повторной аутентификации. У Google Authenticator режим с синхронизацией и режим без Google Account создают разные сценарии потери устройства. Читайте состояние именно используемого приложения.

Не пересылайте QR setup image или TOTP seed самому себе для удобства. Это долговременный секрет, который позволяет другому приложению генерировать действующие коды. Recovery-code file и QR seed требуют разного учёта, но оба нельзя публиковать.

Если recovery code раскрыт или доступ уже закрыт

Код могли увидеть, но доверенная сессия ещё открыта

Не ждите доказательства использования. Из самостоятельно открытых security settings создайте новый набор или key согласно документации сервиса. Для Google и GitHub новый set отменяет старые значения, для Microsoft новый code отменяет предыдущий, Apple позволяет update Recovery Key на trusted device. После ротации проверьте sign-in activity, новые факторы, recovery contacts и незнакомые сессии.

Просьба назвать recovery code «для отмены входа», «проверки владельца» или «подтверждения поддержки» — повод остановить контакт. Google пишет, что не просит backup code вне процесса входа. Практические маркеры помогут распознать срочную просьбу раскрыть код. Не вводите секрет по ссылке собеседника.

Телефон потерян, но есть независимый способ

Используйте ранее зарегистрированный фактор на официальной странице. После входа удалите потерянное устройство, добавьте замену, обновите recovery data и оцените, мог ли посторонний разблокировать телефон. Не выключайте 2FA как постоянное решение. Если на устройстве была главная почта или password manager, завершите их сессии отдельно.

Нет ни кода, ни другого фактора

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

GitHub предупреждает, что Support не может вернуть 2FA-protected account без пригодных recovery methods; отдельные recovery factors могут быть недоступны. Apple с включённым Recovery Key также описывает постоянную блокировку при потере необходимых компонентов. Google и Microsoft имеют recovery flows и sign-in helpers, но успешное прохождение зависит от доступных доказательств и настроек.

Использован один код из списка

Отметьте именно его как использованный в контролируемой копии. Не удаляйте весь рабочий набор и не смешивайте его со старой распечаткой. Генерировать новый set нужно после исчерпания, потери или вероятного раскрытия либо по правилу провайдера. Лишняя ротация без обновления всех копий повышает риск взять недействительный список в кризис.

Аудит комплекта и разделение ответственности

Универсального срока замены recovery code нет. Делайте обзор после смены телефона, номера, password manager, места хранения, работы или семейного плана. Ротация оправдана после утечки, потери копии, исчерпания одноразового списка или требования сервиса. Календарная замена без причины способна оставить в сейфе старый набор, пока владелец ошибочно считает его действующим.

Во время обзора проверяйте метаданные, а не переписывайте секрет в обычный checklist. Достаточно подтвердить: метод виден активным в официальных настройках; независимая копия доступна; другой фактор находится на отдельном носителе; карта содержит актуальную дату; использованные single-use codes отмечены. Не выходите из последней сессии ради демонстрации.

Рабочий или учебный аккаунт

Организация может запретить отдельный метод, применять conditional access или выполнять reset через администратора. Не создавайте личную незарегистрированную копию рабочих секретов и не отключайте 2FA. Сохраните официальный service-desk route и идентификатор устройства. В ticket указывайте время проблемы и потерянный фактор, но не сам recovery code.

Общий логин команды — плохая замена управлению ролями. Нужны отдельные identities, несколько ответственных администраторов и контролируемый break-glass process. Эта статья помогает задать вопросы, но не заменяет security policy организации или инструкции конкретного tenant.

Семейная помощь

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

Recovery code не равен юридическому разрешению на доступ и не заменяет legacy contact, наследственную процедуру или правила сервиса. Технический план должен разделять доступность секрета, право использования и уведомление ответственных лиц.

Практические вопросы

Можно ли держать коды рядом с паспортом?

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

Нужно ли фотографировать бумажную копию?

Обычно это разрушает смысл offline copy: изображение попадает в photo library, cloud sync, backup или мессенджер. Если нужен цифровой вариант, создайте его осознанно в защищённом хранилище и учтите recovery самого хранилища, а не оставляйте случайную фотографию.

Достаточно ли Authenticator backup?

Нет универсального ответа. Полнота зависит от приложения, типа аккаунта и платформы. Microsoft описывает записи, которым после restore нужен повторный sign-in, а cross-platform restore между iOS и Android не поддерживает. Даже при рабочем backup отдельный recovery code уменьшает зависимость, если сервис его предлагает.

Что безопаснее: passkey или код?

Это разные инструменты. Passkey устойчивее к обычному фишинговому вводу, потому что не является строкой, которую можно продиктовать. Recovery code удобен как offline emergency secret. Практический план часто сочетает методы, а не объявляет одного победителя. Не добавляйте passkey на чужом или общедоступном устройстве.

Можно ли проверить код пробным входом?

В Google и GitHub такой тест расходует single-use code. Если это последний независимый способ, эксперимент создаёт лишний риск. Сначала сверяйте статус метода, аккаунт в имени файла и доступность другого фактора. Тест допустим только при понятных правилах платформы и запасном пути.

Что записать в карту без секретов?

Провайдер, тип основного 2FA, тип recovery method, условное место копии, другой фактор, дата проверки и контакт администратора. Не включайте пароль, полный код, TOTP seed, QR image или ответы на security questions. Карта должна объяснять маршрут, а не открывать аккаунт сама.

Границы обещаний

Созданный recovery method снижает риск самоблокировки, но не гарантирует доступ в любой ситуации. Провайдер может изменить интерфейс, ограничить метод для программы усиленной защиты, потребовать другой фактор или отключить подозрительную возможность. Рабочая политика может отличаться от personal account. Поэтому контрольный результат всегда проверяется в текущих настройках.

Документация Google, Apple, Microsoft и GitHub описывает механизмы, а не вероятность успешного восстановления для всех пользователей и не частоту потери доступа в Украине. Статья не ранжирует сервисы и не переносит числа кодов между ними. Самая полезная подготовка — независимая копия плюс другой тип фактора и понятная официальная ветка.

Соберите карту сегодня, пока открыт доверенный сеанс: определите вид recovery method, вынесите копию за пределы основного телефона, добавьте иной способ и запишите дату. После раскрытия ротируйте по правилам провайдера и проверяйте активность; после полной блокировки используйте только официальный recovery process или администратора.

Факты и provider-specific правила проверены 21 августа 2026 года. Названия меню, доступные recovery methods, сроки и ограничения меняются; перед отменой старого фактора сверяйте актуальную официальную справку.