Ключи доступа WebAuthn, QR-коды и Bluetooth: гибридный транспорт

Ключи доступа все чаще заменяют пароли в качестве стандарта де-факто в аутентификации пользователей. В отличие от традиционных паролей, ключи доступа привязаны к экосистеме (например, iCloud Keychain, Google Password Manager, Windows Hello или менеджеру паролей, такому как 1Password или Dashlane); они не предназначены для запоминания, а созданы для бесшовной интеграции с вашими устройствами, предлагая отличный пользовательский опыт «из коробки».

Представьте, что вы находитесь вдали от своего личного компьютера, возможно, за общедоступным терминалом или ноутбуком друга, и вам нужно войти в свою учетную запись, защищенную ключом доступа. Этот сценарий довольно распространен и требует безопасного, но удобного метода аутентификации, но с ключами доступа многие люди не знают, что делать, так как их ключ доступа в этой ситуации недоступен. Одной из функций ключей доступа, которая поможет вам в такой ситуации, является возможность использовать ваши ключи доступа на нескольких устройствах с помощью QR-кодов и технологии Bluetooth. Этот процесс формально известен как гибридный транспорт в спецификации WebAuthn (в предыдущих версиях спецификации он назывался облачный Bluetooth Low Energy caBLE).

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

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

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

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

Ключи доступа синхронизируются в облачных учетных записях, таких как те, что управляются Google Password Manager или Apple iCloud Keychain (Microsoft с Windows Hello скоро последует их примеру), или те, что хранятся в современных менеджерах паролей, готовых к работе с ключами доступа, таких как 1Password или Dashlane. Однако важно знать, что по умолчанию ключи доступа привязаны к экосистеме и соответствующей синхронизации облачной учетной записи. Операционные системы не предоставляют интерфейса для экспорта закрытых ключей, и на большинстве устройств есть аппаратный компонент, обеспечивающий дополнительные меры безопасности для предотвращения любого доступа к закрытым ключам, например, Secure Enclave на устройствах iOS или Trusted Platform Module (TPM) на устройствах Windows. Только поставщик операционной системы может синхронизировать ключи доступа с другими устройствами в зашифрованном виде (в конечном итоге защищенном биометрией, паролем или PIN-кодом пользователя). Закрытые ключи могут быть восстановлены и расшифрованы только с помощью пароля / PIN-кода и будут уничтожены в случае слишком большого количества неудачных попыток входа в облачную учетную запись (например, Apple вводит ограничение скорости для предотвращения атак методом перебора даже с привилегированной позиции на облачном бэкенде; Google делает то же самое).

Этот неотъемлемый дизайн означает, что если ключи доступа не синхронизированы, как описано, доступ к вашим ключам доступа на новом устройстве может стать проблемой. Именно поэтому существует метод гибридного транспорта для кроссплатформенной аутентификации с помощью ключей доступа с использованием QR-кода и проверки близости по Bluetooth. Он обеспечивает безопасный мост для ваших ключей доступа между устройствами без необходимости их синхронизации через облачную учетную запись / менеджер паролей, тем самым поддерживая принцип, что ключи доступа могут оставаться исключительно у пользователя.

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

Для обеспечения кроссплатформенной аутентификации с помощью ключей доступа (гибридный транспорт) существуют следующие аппаратные требования:

• Поддержка WebAuthn: Устройства должны поддерживать WebAuthn. Это уже реализовано на 99% устройств, согласно нашему последнему анализу данных о готовности к использованию ключей доступа.
• Камера для сканирования QR-кодов: Устройствам потребуется камера, способная сканировать QR-коды. Большинство современных смартфонов оснащены камерами с этой функциональностью. Более того, камера должна иметь встроенные возможности сканирования QR-кодов (что есть у большинства устройств «из коробки»). Если ваша камера не поддерживает эту функцию, то онлайн-сканер QR-кодов также является хорошим вариантом. В противном случае, установка приложения для сканирования QR-кодов тоже подойдет.
• Возможность Bluetooth: Облачный Bluetooth Low Energy (caBLE) используется для установления безопасного соединения между устройствами на основе их близости. Следует искать версии Bluetooth 4.0 или выше, которые поддерживают расширение caBLE для WebAuthn.
• Подключение к Интернету: На обоих устройствах должно быть стабильное подключение к Интернету, так как обмен данными включает открытие туннеля для выполнения шагов проверки, требующих передачи данных в реальном времени.

С точки зрения программного обеспечения существуют следующие требования:

• Конфигурация сервера WebAuthn: Очевидно, вам нужен сервер WebAuthn, который управляет открытыми ключами. Это также включает в себя возможность связывания учетной записи пользователя с несколькими аутентификаторами и настройку сервера для инициации церемонии аутентификации.
• Web Bluetooth API: Для проверки близости по Bluetooth вам потребуется доступ к Web Bluetooth API, который активирует возможности Bluetooth устройства из браузера.
• Требования к операционной системе: Пожалуйста, ознакомьтесь со следующей таблицей о поддержке кросс-устройственной аутентификации для различных операционных систем по состоянию на март 2025 года. Аутентификатор означает, что устройство может служить устройством, которое хранит ключ доступа (в нашем сценарии — смартфон). Клиент означает устройство, которое создает QR-код и на котором пользователь пытается войти (в нашем сценарии — настольный компьютер):

Источник: passkeys.dev

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

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

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

Пользователь сканирует этот QR-код устройством, на котором доступен его ключ доступа. Меры безопасности включают:

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

Отсканированный QR-код содержит специальный URI со схемой FIDO, например: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

Сканирование QR-кода заставляет второе устройство пользователя (например, смартфон или планшет) интерпретировать URI FIDO и связаться с сервером аутентификации, отправляя сигнал о том, что пользователь пытается аутентифицироваться через новое устройство (например, ноутбук друга). Это действие побуждает сервер сгенерировать криптографический вызов, уникальный для этой попытки аутентификации.

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

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

Некоторые важные аспекты конфиденциальности и безопасности, которые следует учитывать:

• Нет обмена данными по Bluetooth, только Интернет: Важно отметить, что в этой кроссплатформенной аутентификации с помощью ключей доступа на основе QR-кода (гибридный транспорт) Bluetooth не участвует в обмене данными. Этот процесс полностью зависит от подключения к Интернету для передачи зашифрованных данных между устройствами и сервером. Однако Bluetooth используется для проверки близости двух устройств.
• Закрытые ключи не покидают устройство: На протяжении всего этого процесса закрытые ключи пользователя надежно остаются на его устройстве.
• Нет раскрытия конфиденциальных данных: Никакая конфиденциальная информация о ключах доступа или закрытых ключах не передается и не раскрывается во время процесса аутентификации.
• Асимметричная криптография: Механизм «вызов-ответ» гарантирует, что отправляются только неповторяемые, подписанные версии вызовов, которые не могут быть использованы для несанкционированного доступа.

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

Помимо процесса сканирования QR-кода, существует также проверка близости через Bluetooth (caBLE). Уверенность в том, что клиент и аутентификатор физически близки друг к другу, является одним из основных преимуществ протокола WebAuthn. Более подробная информация о том, как работает этот процесс, описана ниже:

Bluetooth Low Energy (BLE) — это технология беспроводной связи, предназначенная для обмена данными на коротких расстояниях. Она играет ключевую роль в подтверждении физической близости устройств во время процесса аутентификации.

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

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

Представьте, что вы получили QR-код, который перенаправляет на вредоносный сайт. Если аутентификация выполняется через этот QR-код, существует риск, что сессия или cookie могут быть перехвачены. BLE обходит эту проблему, не полагаясь на визуальное сканирование, а на физическое присутствие устройств. Эта проверка близости минимизирует риск атак «человек посередине», так как проверка близости не происходит через Интернет или визуальную среду.

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

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

Существуют следующие преимущества этого метода кроссплатформенной аутентификации с помощью ключей доступа (гибридный транспорт):

Кроссплатформенная аутентификация с помощью ключей доступа через QR-код и Bluetooth (гибридный транспорт) — это способ улучшить UX в кроссплатформенных сценариях по сравнению с отсутствием какой-либо возможности вообще. Однако этот пользовательский поток абсолютно нов для большинства пользователей, и мы не ожидаем, что многие нетехнические пользователи поймут, что происходит, когда они впервые столкнутся с этим потоком. Единственное сходство с введением потока QR-кода можно найти в потоках входа, например, для WhatsApp Web или Discord, где используются QR-коды (хотя функциональность там другая). Таким образом, проанализированный процесс кроссплатформенной аутентификации с помощью ключей доступа через QR-код / Bluetooth (гибридный транспорт) минимизирует усилия пользователя в кроссплатформенном сценарии, так как нет необходимости вручную вводить какие-либо учетные данные, но общий поток все еще неизвестен большинству пользователей.

Безопасность кроссплатформенной аутентификации с помощью ключей доступа (гибридный транспорт) усиливается передовыми криптографическими методами. Когда QR-код сканируется или устанавливается соединение Bluetooth для аутентификации, криптографические вызовы и ответы гарантируют, что только предполагаемое устройство может успешно завершить процесс аутентификации.

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

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

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

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

Существуют следующие недостатки этого метода кроссплатформенной аутентификации с помощью ключей доступа (гибридный транспорт):

Внедрение любой новой технологии может привести к путанице у пользователей, особенно если они не разбираются в технике. Кроссплатформенная аутентификация с помощью ключей доступа через QR-код и Bluetooth (гибридный транспорт) — это значительный отход от традиционных методов аутентификации, и некоторым пользователям может быть сложно освоить новый процесс, что потенциально приведет к более медленному внедрению. Однако мы ожидаем, что со временем пользователи привыкнут к этому, поэтому изменение может быть сложнее вначале, но со временем станет более плавным и приемлемым.

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

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

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

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

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

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

В качестве оговорки: в следующем тесте мы игнорируем аппаратные ключи безопасности (например, YubiKey) и используем только платформенные аутентификаторы, встроенные в устройства (например, Face ID, Touch ID, Windows Hello). В случае аппаратных ключей безопасности (например, YubiKey) значения для transports были бы, например, usb или nfc.

Мы используем следующие комбинации устройств / браузеров и Passkeys Debugger для тестирования поведения. Android не рассматривается, так как Android не может служить клиентом для кроссплатформенной аутентификации (гибридный транспорт) (см. таблицу выше).

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

• userName: alex muller (не влияет на этот тест)
• authenticatorAttachment: platform (поскольку мы хотим исключить аппаратные ключи безопасности, такие как YubiKey)
• residentKey: preferred (не влияет на этот тест)
• userVerification: preferred (не влияет на этот тест)
• attestation: none (не влияет на этот тест)
• hints: empty (см. объяснение ниже)
• usePRF: no (не влияет на этот тест)

После успешного создания ключа доступа мы изменяем входные данные свойства сервера WebAuthn allowCredentials и инициируем запрос на вход. Мы хотим имитировать удаленный ключ доступа на устройстве, где мы его создали, чтобы устройство / браузер искал другое устройство, которое может предоставить ключ доступа через QR-код / Bluetooth. Поэтому мы изменяем credential ID и присваиваем значение CHANGED-ID, чтобы сопоставление не удалось. Кроме того, мы изменяем свойство transports учетных данных WebAuthn в allowCredentials и присваиваем для каждой комбинации устройства / браузера следующие значения:

1. transports: [internal, hybrid]: Ключи доступа могут использоваться с платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello) или через кроссплатформенную аутентификацию
2. transports: [internal]: Ключи доступа могут использоваться с платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello)
3. Свойство transports не установлено: поведение по умолчанию, которое не накладывает ограничений

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

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

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

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код, через известные устройства и через аппаратные ключи безопасности.

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

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

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код, через известные устройства и через аппаратные ключи безопасности.

При создании ключа доступа мы получили следующую ошибку (но ключ доступа все же был создан):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

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

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код, через известные устройства и через аппаратные ключи безопасности.

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

Модальное окно сильно отличается от аналога на Windows в Chrome 119.

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор. Кроме того, вы можете напрямую выбрать одно из известных устройств, чтобы использовать ключ доступа оттуда.

Модальное окно сильно отличается от аналога на Windows в Chrome 119.

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Touch ID, через QR-код, через известные устройства и через аппаратные ключи безопасности.

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

Как и ожидалось, разрешены большинство форм аутентификации с помощью ключей доступа: через Touch ID, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

Как и ожидалось, разрешены большинство форм аутентификации с помощью ключей доступа: через Face ID, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

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

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

Как и ожидалось, разрешены большинство форм аутентификации с помощью ключей доступа: через Face ID, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

Далее, для устройств с Windows 10 мы решили пойти на один уровень дальше и проанализировать, как выглядит поведение, если Bluetooth отключен или вообще недоступен на машине с Windows 10. В частности, для старых настольных устройств это все еще очень распространенный сценарий, так как эти устройства часто не имеют модуля Bluetooth, что делает кроссплатформенную аутентификацию через QR-код и Bluetooth невозможной.

8.8.1.1 transports: [internal, hybrid]

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа - первый скриншот) или выбрать сканирование QR-кода (второй скриншот).

8.8.1.2 transports: [internal]

Довольно запутанно, но вам предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.8.1.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.8.1.4 Пустой allowCredentials

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код, через известные устройства и через аппаратные ключи безопасности.

8.8.2.1 transports: [internal, hybrid]

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

8.8.2.2 transports: [internal]

Это поведение аналогично случаю, когда Bluetooth включен. Очень запутанно, что пользователю предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.8.2.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому единственный вариант, который у вас есть, — это использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.8.2.4 Пустой allowCredentials

Аутентификация с помощью ключей доступа возможна только через Windows Hello и аппаратные ключи безопасности.

8.9.1.1 transports: [internal, hybrid]

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

8.9.1.2 transports: [internal]

Довольно запутанно, но вам предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.9.1.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.9.1.4 Пустой allowCredentials

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

8.9.2.1 transports: [internal, hybrid]

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

8.9.2.2 transports: [internal]

Это поведение аналогично случаю, когда Bluetooth включен. Очень запутанно, что пользователю предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.9.2.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому единственный вариант, который у вас есть, — это использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.9.2.4 Пустой allowCredentials

Аутентификация с помощью ключей доступа возможна только через Windows Hello и аппаратные ключи безопасности.

8.10.1.1 transports: [internal, hybrid]

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

8.10.1.2 transports: [internal]

Довольно запутанно, но вам предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.10.1.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.10.1.4 Пустой allowCredentials

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

8.10.2.1 transports: [internal, hybrid]

Это действительно запутанное сообщение для пользователей, так как не указано явно, что им следует делать и как они могут аутентифицироваться. Единственный вариант, который у них есть, — это нажать «Отмена», что делает этот сценарий тупиковым. По какой-то причине часть модального окна Windows Security также отображается на немецком языке (второй язык, установленный на этом устройстве).

8.10.2.2 transports: [internal]

Это поведение аналогично случаю, когда Bluetooth включен. Очень запутанно, что пользователю предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.10.2.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому единственный вариант, который у вас есть, — это использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.10.2.4 Пустой allowCredentials

Аутентификация с помощью ключей доступа возможна только через Windows Hello и аппаратные ключи безопасности.

8.11.1.1 transports: [internal, hybrid]

Как и ожидалось, локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код и использовать ключ доступа на другом устройстве (поскольку система знает, что для этого пользователя существует ключ доступа).

8.11.1.2 transports: [internal]

Довольно запутанно, но вам предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.11.1.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому предлагается отсканировать QR-код или использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.11.1.4 Пустой allowCredentials

Как и ожидалось, разрешены все формы аутентификации с помощью ключей доступа: через Windows Hello, через QR-код и через аппаратные ключи безопасности. По какой-то причине известные устройства не отображаются.

8.11.2.1 transports: [internal, hybrid]

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

8.11.2.2 transports: [internal]

Это поведение аналогично случаю, когда Bluetooth включен. Очень запутанно, что пользователю предлагается ввести PIN-код Windows Hello (или отпечаток пальца / сканирование лица, если настроено на устройстве), хотя мы изменили credential ID (поэтому он на самом деле не должен находить учетные данные, так как они не указаны в свойстве allowCredentials). Однако после отправки PIN-кода Windows Hello возникает ошибка: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." С точки зрения пользователя, это довольно запутанное поведение, но оно имеет смысл, так как может предоставить информацию о ключах доступа пользователя без его согласия.

8.11.2.3 Свойство transports не установлено

Локальный ключ доступа не найден, поэтому единственный вариант, который у вас есть, — это использовать аппаратный ключ безопасности (например, YubiKey) / кроссплатформенный аутентификатор / роуминговый аутентификатор.

8.11.2.4 Пустой allowCredentials

Аутентификация с помощью ключей доступа возможна только через Windows Hello и аппаратные ключи безопасности.

• Используйте библиотеки и фреймворки, которые абстрагируют некоторые сложности чистого WebAuthn API.
• Рассматривайте сценарии кроссплатформенной аутентификации с самого начала, чтобы обеспечить широкой пользовательской базе возможность воспользоваться вашей реализацией ключей доступа. В зависимости от вашего выбора дизайна, вы также можете предложить альтернативные методы входа в этих сценариях.
• Разрабатывайте резервные механизмы для сценариев, когда кроссплатформенная аутентификация с помощью ключей доступа (гибридный транспорт) может быть невозможна из-за ограничений устройства.
• Самое большое дизайнерское решение — решить, хотите ли вы продвигать кроссплатформенную аутентификацию с помощью ключей доступа через QR-код / Bluetooth (гибридный транспорт) и сделать ее основным методом аутентификации с помощью ключей доступа или использовать подсказки, чтобы не продвигать ее активно. В последнем случае всегда делается попытка немедленно использовать внутренне сохраненные ключи доступа, и только если внутренний ключ доступа не найден, отображается QR-код для кроссплатформенной аутентификации (гибридный транспорт). Это необходимо определить в опциях вашего сервера WebAuthn в свойствах excludeCredentials и allowCredentials. В свойстве excludeCredentials вашего сервера WebAuthn вы можете видеть информацию о транспорте уже созданных учетных данных. В свойстве allowCredentials вы можете указать поведение в процессе входа (см. тесты выше).
• Более того, вы не можете полностью предотвратить кроссплатформенную аутентификацию с помощью ключей доступа (гибридный транспорт) (см. тесты выше с transports: [internal]), поэтому вам нужно быть готовым к тому, что ваши пользователи найдут этот метод и у них возникнут вопросы. Возникновение этой кроссплатформенной аутентификации (гибридный транспорт) будет происходить, в частности, если пользователи начнут локально удалять ключи доступа.

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

• Внедряйте сеансы с ограниченным временем для входа с помощью ключей доступа через QR-код или Bluetooth, чтобы обеспечить временный и безопасный доступ.
• Убедитесь, что кроссплатформенная аутентификация с помощью ключей доступа (гибридный транспорт) не подрывает существующие протоколы безопасности, сохраняя целостность пользовательских данных.
• Учитывайте последствия для конфиденциальности и убедитесь, что любой временный доступ, предоставленный через кроссплатформенную аутентификацию с помощью ключей доступа (гибридный транспорт), регистрируется и отслеживается в соответствии с лучшими практиками безопасности.

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

Мы надеемся, что смогли пролить свет на тему кроссплатформенной аутентификации с помощью ключей доступа (гибридный транспорт) через QR-код / Bluetooth, объяснить, как все настроить и как выглядит поведение на различных комбинациях устройств / браузеров. Если у вас есть какие-либо вопросы, не стесняйтесь обращаться к нам через наше сообщество по ключам доступа или подписывайтесь на наш Substack по ключам доступа. Давайте сделаем Интернет безопаснее, распространяя ключи доступа.