FIDO2: WebAuthn, ключи доступа и безопасность (RU)

FIDO2 включает два стандарта аутентификации с открытым ключом: API веб-аутентификации Консорциума Всемирной паутины (WebAuthn) и Протокол клиента FIDO Alliance для аутентификатора (CTAP). Вместе они позволяют полагающейся стороне регистрировать и использовать криптографические учетные данные без хранения многоразового общего секрета, такого как пароль.

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

Основные выводы

• FIDO2 — это WebAuthn плюс CTAP. WebAuthn соединяет веб-сайт или приложение с клиентом; CTAP соединяет клиентскую платформу с роуминговым аутентификатором.
• Закрытый ключ остается у аутентификатора. Полагающаяся сторона хранит открытый ключ и проверяет подписи по свежим запросам и ограниченному контексту.
• Привязка к домену создает устойчивость к фишингу. Учетные данные, зарегистрированные для одного идентификатора полагающейся стороны, не могут быть просто повторно использованы в несвязанном домене злоумышленника.
• Ключи доступа — это учетные данные FIDO. Они могут быть привязаны к устройству или синхронизированы между устройствами провайдера, создавая различные компромиссы в отношении обеспечения, восстановления и переносимости.
• Восстановление является частью модели безопасности. Надежный вход в FIDO2 может быть обойден, если пути восстановления электронной почты, поддержки или личности могут заменить учетные данные более слабыми доказательствами.

Что такое FIDO2?

Обзор спецификаций FIDO Alliance определяет FIDO2 как комбинацию спецификации W3C WebAuthn и протоколов FIDO Client to Authenticator. Стандарты делят систему на взаимодействующие роли:

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

Спецификация W3C WebAuthn Level 3 определяет веб-API для создания и использования учетных данных с открытым ключом, ограниченных полагающейся стороной. Скрипты никогда не получают закрытый ключ учетных данных. Они получают структурированные данные и криптографические доказательства, полученные через аутентификатор и клиент.

Сравнение FIDO2, WebAuthn, CTAP, U2F и ключей доступа

Термин	Практическое значение	Основная граница
FIDO2	Совместное использование стандартов WebAuthn и CTAP	Полное семейство стандартов, а не один вызов API
WebAuthn	API браузера или клиента и модель данных полагающейся стороны для учетных данных с открытым ключом	Соединяет полагающуюся сторону с клиентом
CTAP2	Протокол между клиентской платформой и роуминговым аутентификатором	Передает связь внешнего аутентификатора по таким протоколам, как USB, NFC и BLE
U2F / CTAP1	Более ранний протокол FIDO, обычно связанный с ключами безопасности второго фактора	Более ограничен, чем современные возможности FIDO2
Ключ доступа	Обнаруживаемые учетные данные FIDO, предназначенные для беспарольного входа	Могут быть синхронизированы или привязаны к устройству
Ключ безопасности	Роуминговый аппаратный аутентификатор, подключенный по USB, NFC или другому поддерживаемому протоколу	Одна из возможных форм аутентификатора
Платформенный аутентификатор	Аутентификатор, встроенный в устройство или операционную систему	Часто активируется локальным PIN-кодом или биометрией

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

Как работает регистрация FIDO2

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

1. Сервер создает параметры регистрации

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

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

2. Клиент вызывает WebAuthn

Приложение вызывает navigator.credentials.create() с параметрами открытого ключа. Браузер проверяет источник и контекст безопасности, затем просит доступный аутентификатор создать учетные данные.

3. Аутентификатор получает согласие пользователя

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

Локальная биометрия обычно разблокирует использование учетных данных; биометрический шаблон не отправляется на веб-сайт в качестве секрета аутентификации.

4. Аутентификатор создает пару ключей

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

5. Сервер проверяет и сохраняет учетные данные

Полагающаяся сторона проверяет процедуру перед сохранением чего-либо. Проверки включают:

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

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

Как работает аутентификация FIDO2

Аутентификация доказывает контроль над ранее зарегистрированными учетными данными.

1. Сервер создает параметры запроса

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

2. Клиент запрашивает утверждение

Приложение вызывает navigator.credentials.get(). Браузер и аутентификатор выбирают подходящие учетные данные и получают необходимое присутствие пользователя или локальную верификацию пользователя.

3. Аутентификатор подписывает данные процедуры

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

4. Сервер проверяет утверждение

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

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

Почему FIDO2 устойчив к фишингу

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

Требования к аутентификаторам NIST SP 800-63B-4 описывают WebAuthn как устойчивый к фишингу благодаря привязке к имени верификатора. Вывод аутентификатора привязан к аутентифицированному доменному имени вместо того, чтобы зависеть от того, заметит ли пользователь обманчивую страницу.

Устойчивость к фишингу имеет границы:

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

Устойчивость к повторным атакам и обработка запросов

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

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

Сервер должен атомарно пометить запрос как использованный. Если параллельные запросы конкурируют, только одна успешная процедура должна иметь возможность использовать этот запрос.

Присутствие пользователя и верификация пользователя

WebAuthn различает:

• Присутствие пользователя (UP): пользователь выполнил взаимодействие, указывающее на участие.
• Верификация пользователя (UV): аутентификатор локально верифицировал пользователя с помощью фактора активации, такого как PIN-код или биометрические данные.

Одно только присутствие не является многофакторной аутентификацией. Служба, защищающая действие с более высоким риском, может требовать флаг UV и отклонять утверждения, которые показывают только присутствие. Требования должны указывать ожидаемые значения флагов, а не полагаться на метку интерфейса, такую как «Использовать Face ID».

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

Платформенные, роуминговые и кросс-устройственные аутентификаторы

Платформенные аутентификаторы

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

Роуминговые аутентификаторы

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

Кросс-устройственная аутентификация

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

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

Привязанные к устройству и синхронизированные ключи доступа

Ключ доступа — это учетные данные FIDO, предназначенные для входа без пароля. Ключи доступа могут быть:

• Привязаны к устройству: закрытый ключ учетных данных остается привязанным к одному аутентификатору или управляемому устройству.
• Синхронизированы: материал учетных данных шифруется и синхронизируется через структуру провайдера для использования на подходящих устройствах.

Синхронизированные ключи доступа улучшают доступность и восстановление, в то время как привязанные к устройству учетные данные могут обеспечить более сильную неэкспортируемость. Руководство NIST SP 800-63B-4 по синхронизируемым аутентификаторам допускает синхронизируемые аутентификаторы в контекстах до уровня обеспечения аутентификации 2 при соблюдении его требований, но синхронизация конфликтует с неэкспортируемостью, требуемой на уровне 3.

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

Аттестация и доверие к аутентификатору

Аттестация может предоставить доказательства происхождения или свойств аутентификатора при регистрации. Она не идентифицирует человека-пользователя и не является тем же, что и подпись аутентификации.

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

Если используется аттестация:

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

FIDO2 не заменяет подтверждение личности

FIDO2 доказывает контроль над учетными данными, зарегистрированными у полагающейся стороны. Он не устанавливает юридическое имя, возраст, адрес, регуляторный статус или реальную уникальность человека, регистрирующего их.

Это различие создает три общих шаблона:

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

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

Восстановление учетной записи и жизненный цикл учетных данных

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

Полный жизненный цикл охватывает:

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

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

Как оценивать развертывание FIDO2

Проверка протокола

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

Покрытие аутентификатора

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

Безопасность учетной записи и сессии

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

Восстановление и поддержка

Моделируйте ситуации потери, кражи устройств, скомпрометированной электронной почты, смены SIM-карты, выдачи себя за сотрудника поддержки и злонамеренного доступа в доме или на работе. Измеряйте как устойчивость к атакам, так и успешность выполнения для подлинного пользователя.

Конфиденциальность и наблюдаемость

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

Распространенные ошибки реализации FIDO2

Проверка подписи, но не контекста

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

Называние каждого ключа доступа многофакторным

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

Разрешение бесшумного добавления учетных данных

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

Поддержка только одних учетных данных

Учетные записи с одним учетными данными создают хрупкое восстановление и способствуют более слабым резервным вариантам. Разрешите несколько аутентификаторов с четким управлением и отзывом.

Оставление пароля в качестве равноценного запасного варианта

Если пароль всегда может обойти путь FIDO, устойчивость к фишингу может существовать только на предпочтительной кнопке. Ограничьте или удалите более слабые пути в соответствии с риском и этапом миграции.

Игнорирование серверных сессий

FIDO2 аутентифицирует процедуру входа. Защищайте файлы cookie и токены, ротируйте сессии после аутентификации, требуйте повышения уровня для конфиденциальных действий и отзывайте скомпрометированные сессии.

Контрольный список развертывания

Перед запуском убедитесь, что:

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

Место Didit рядом с FIDO2

FIDO2 обрабатывает аутентификацию после регистрации учетных данных. Didit может поддерживать смежное решение по идентификации с помощью проверки личности, определения живости и биометрической аутентификации. Опубликованные цены на биометрическую аутентификацию составляют 0,10 доллара США за проверку.

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

Часто задаваемые вопросы

Что означает FIDO2?

FIDO означает Fast Identity Online (Быстрая онлайн-идентификация). FIDO2 — это семейство стандартов, объединяющее W3C WebAuthn с FIDO Alliance CTAP для аутентификации с открытым ключом.

FIDO2 то же самое, что и WebAuthn?

Нет. WebAuthn определяет API полагающейся стороны и клиента, а также модель данных. FIDO2 включает WebAuthn плюс CTAP, который соединяет клиентскую платформу с роуминговыми аутентификаторами.

Являются ли ключи доступа учетными данными FIDO2?

Да. Ключи доступа — это обнаруживаемые учетные данные FIDO, предназначенные для беспарольного входа. Они могут быть синхронизированы между подходящими устройствами или оставаться привязанными к устройству.

Устойчив ли FIDO2 к фишингу?

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

Использует ли FIDO2 биометрию?

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

Проверяет ли FIDO2 личность человека?

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

Что происходит, когда пользователь теряет все аутентификаторы?

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

Основные ссылки

• Спецификации аутентификации пользователя FIDO Alliance
• Рекомендация-кандидат W3C Web Authentication Level 3
• Предлагаемый стандарт FIDO Alliance CTAP 2.3
• NIST SP 800-63B-4: Управление аутентификацией и аутентификаторами
• Требования к аутентификаторам NIST SP 800-63B-4

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