FIDO2 и passkeys: как устроен стандарт, лежащий в основе ключей доступа

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

Главный практический вывод сразу: FIDO2 — это не один протокол, а связка из двух спецификаций. WebAuthn описывает диалог между браузером (или приложением) и сервером, а CTAP — диалог между устройством-клиентом и самим аутентификатором: USB-ключом, смартфоном, модулем ноутбука. Понимание этого разделения помогает правильно оценивать совместимость устройств и выбирать сценарии внедрения.

Что такое FIDO2 и зачем он появился

FIDO2 — второе поколение стандартов альянса FIDO (Fast IDentity Online), консорциума, в который входят крупные производители браузеров, платформ и сервисов. Задача стандарта — заменить передачу пароля по сети на асимметричную криптографию с привязкой к устройству.

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

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

Важно понимать: FIDO2 защищает от перехвата и подмены сайта, но не заменяет контроль над самим устройством. Если злоумышленник получил разблокированный телефон или ноутбук вместе с PIN-кодом, часть защит перестаёт работать. Это ограничение любой системы, где фактор владения является основным.

Архитектура: два протокола и три участника

В каждой операции FIDO2 участвуют три стороны, и полезно различать их роли.

Клиент (браузер или приложение)

Браузер реализует WebAuthn — JavaScript API, через который сайт запрашивает создание учётных данных или их предъявление. Браузер выступает посредником: он получает запрос от сайта, передаёт его операционной системе, а та обращается к доступным аутентификаторам. Именно поэтому поддержка зависит одновременно от трёх слоёв: браузера, ОС и самого устройства.

Аутентификатор

Это компонент, который хранит приватные ключи и выполняет подписывание. Аутентификаторы делятся на две категории:

• Платформенные — встроены в устройство: Touch ID и Secure Enclave на Mac, Windows Hello с TPM на ПК, биометрия и защищённое хранилище на смартфонах. Ключ физически нельзя извлечь из чипа.
• Роуминговые — отдельные устройства, подключаемые по USB, NFC или Bluetooth: классические «флешки» безопасности. Они подходят для машин, где нет встроенного аутентификатора, и для сценариев с повышенными требованиями к хранению.

Сервер (relying party)

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

Связка CTAP описывает транспорт между клиентом и роуминговым аутентификатором: как браузер обнаруживает подключённый по USB ключ, как передаются команды по NFC при поднесении телефона или карты, как работает гибридный режим, когда телефон выступает аутентификатором для компьютера через Bluetooth с подтверждением близости.

Как проходит регистрация и вход

Логику стандарта проще всего увидеть на двух процедурах.

Регистрация учётных данных

1. Сайт просит браузер создать новые учётные данные и передаёт параметры: идентификатор домена, идентификатор пользователя, требования к аутентификатору.
2. Аутентификатор генерирует новую пару ключей, уникальную для этого сайта. Один сервис — одна пара, что исключает отслеживание пользователя между сайтами по общему ключу.
3. Приватный ключ остаётся в аутентификаторе. Публичный ключ вместе с аттестацией (подтверждением модели и происхождения устройства) возвращается серверу.
4. Сервер связывает публичный ключ с учётной записью. Регистрация завершена.

Аутентификация

1. Сервер отправляет случайный вызов (challenge) — одноразовое значение, которое нельзя переиспользовать.
2. Аутентификатор после локальной проверки пользователя (PIN, отпечаток, распознавание лица) подписывает вызов приватным ключом.
3. Подпись и счётчик использований уходят на сервер.
4. Сервер проверяет подпись публичным ключом, сверяет счётчик и убеждается, что вызов свежий. Вход разрешён.

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

Passkeys: синхронизируемые ключи доступа

Изначально модель FIDO2 предполагала, что учётные данные живут внутри одного устройства, и потеря ноутбука означала потерю доступа. Практика показала, что это главный барьер массового adoption, поэтому индустрия добавила синхронизацию: приватные ключи шифруются и реплицируются через облачное хранилище экосистемы — связку ключей Apple или менеджер паролей Google, а также сторонние менеджеры, поддерживающие формат.

Это меняет модель угрозы, и об этом важно говорить прямо:

• Плюс: восстановление при потере устройства становится штатной процедурой, как восстановление контактов. Барьер для обычного пользователя исчезает.
• Минус: защита теперь упирается в безопасность облачной учётной записи. Компрометация аккаунта экосистемы потенциально открывает доступ к passkeys, поэтому сама эта учётная запись должна быть максимально защищена.
• Нюанс: переносимость между экосистемами развивается, но на практике многие пользователи остаются привязанными к одной платформе. Перед полным отказом от паролей стоит проверить, поддерживает ли ваш набор устройств нужные сценарии переноса.

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

Сравнение вариантов аутентификации

Критерий	Пароль + SMS-код	Синхронизируемый passkey	Аппаратный ключ FIDO2
Устойчивость к фишингу	Низкая	Высокая	Высокая
Зависимость от сети и SMS	Есть	Только для синхронизации	Нет
Восстановление при потере устройства	Через сброс пароля	Автоматическое через облако	Только резервный ключ
Риск централизованной компрометации	База паролей сервиса	Аккаунт экосистемы	Минимальный
Удобство для обычного пользователя	Среднее	Высокое	Требует носить устройство
Типичное применение	Устаревающие системы	Личные аккаунты, массовые сервисы	Корпоративный доступ, критичные системы

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

Что проверить перед переходом на passkeys

Перед тем как отключать пароли или делать passkey основным методом входа, пройдитесь по списку:

• Поддерживают ли все ваши повседневные браузеры и операционные системы WebAuthn в нужной версии. Поддержка появилась давно, но детали вроде управления passkeys в настройках различаются между платформами.
• Есть ли у сервиса сценарий восстановления, если вы потеряете все устройства с ключами. Хороший сервис предлагает несколько независимых способов: второй passkey, резервные коды, аппаратный ключ.
• Работает ли кроссплатформенный вход там, где он вам нужен: например, вход с Windows-ноутбука с помощью iPhone через гибридный режим требует Bluetooth у обоих устройств.
• Не останется ли пароль активным параллельно с passkey. Пока оба метода включены, атакующий может использовать более слабый из них.
• Для организаций: поддерживает ли ваша система управления идентификацией аттестацию устройств и политики по типам аутентификаторов, если требуется ограничить, какие ключи считаются допустимыми.

Типичные ошибки и заблуждения

«Passkey — это просто новый пароль». Нет: пароль — общий секрет, который вводится и проверяется на сервере. Passkey — приватный ключ, который никуда не отправляется. Следствия принципиально разные: фишинг и утечки базы перестают работать как векторы атаки.

«Один passkey на всё». По стандарту для каждого сайта создаётся своя пара ключей. Если вы удалили passkey для одного сервиса, остальные не затрагиваются — но и универсального «мастер-ключа», которым можно войти куда угодно, не существует.

«Настроил и забыл про резервирование». Самая частая практическая ошибка. Перед удалением паролей создайте минимум два независимых способа входа и убедитесь, что резервный способ реально проверен входом, а не просто числится в настройках.

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

Сценарии: когда какой подход уместен

• Личные аккаунты (почта, соцсети, магазины): синхронизируемые passkeys как основной метод плюс резервный код, сохранённый офлайн. Баланс безопасности и восстанавливаемости здесь обычно оптимален.
• Рабочий ноутбук одного человека: платформенный аутентификатор (Windows Hello, Touch ID) с политикой обязательного PIN и блокировки экрана.
• Административный доступ и финансовые операции: аппаратный ключ как основной, второй ключ — в сейфе или у доверенного лица. Синхронизация сознательно отключается.
• Общий компьютер или киоск: роуминговый ключ, который пользователь приносит с собой и забирает после работы; на самом устройстве учётные данные не остаются.

Ограничения и открытые вопросы

Честная оценка технологии включает её слабые места. Совместимость фрагментирована: возможности зависят от тройки «браузер — ОС — аутентификатор», и редкие комбинации могут не работать. Перенос passkeys между экосистемами разных производителей развивается, но его поддержку конкретными сервисами нужно проверять отдельно. Управление большим количеством passkeys в настройках устройств пока менее удобно, чем управление записями в зрелых менеджерах паролей. Наконец, миграция корпоративных систем занимает годы: legacy-приложения без поддержки WebAuthn продолжают требовать пароли, и организации вынуждены жить в гибридном режиме.

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

С чего начать на практике

Если вы обычный пользователь, разумная последовательность такая: выберите один важный сервис с поддержкой passkeys, создайте ключ доступа, затем создайте второй способ входа (резервный код или passkey на другом устройстве) и только после реальной проверки обоих способов отключайте пароль. Повторите для остальных сервисов по мере готовности.

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

Главный принцип выбора прост: безопасность входа определяется самым слабым из оставшихся методов. FIDO2 и passkeys сильны ровно настолько, насколько последовательно вы убираете парольные пути обхода и резервируете восстановление.

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