Могут ли passkeys создавать отпечаток? Границы WebAuthn

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

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

Спецификация WebAuthn Level 3 определяет интерфейсы браузера и процедуры работы с учётными данными. Справочник MDN по PublicKeyCredential описывает интерфейс для браузера. Вместе они поддерживают аккуратную модель: доступность возможности, проверка пользователя, использование аутентификатора, создание учётных данных и их получение связаны, но являются разными событиями.

Кратко

• isUserVerifyingPlatformAuthenticatorAvailable() возвращает логическое значение о том, можно ли сейчас обнаружить платформенный аутентификатор с проверкой пользователя, и не называет ни аутентификатор, ни датчик, ни учётную запись, ни учётные данные.
• isConditionalMediationAvailable() сообщает только о доступности условного посредничества, а не о результате входа, поэтому отсутствующий метод или значение false требуют другой видимой дороги.
• Защищённый контекст, origin и RP ID ограничивают каждую процедуру: navigator.credentials.create() и navigator.credentials.get() дают проверяемый сервером результат только для RP ID, подписавшего вызов.
• Отменённое приглашение, просроченный вызов, несовпадение RP ID и недоступный аутентификатор это четыре разных исхода, и ни один из них не относится к постоянному атрибуту учётной записи.
• BotBrowser может повторить документированную конфигурацию возможностей клиента, чтобы убедиться, что страница входа сохраняет запасной путь, но он не создаёт оборудование аутентификатора, не записывает учётные данные и не проверяет утверждение.

Содержание

• Смотреть видео
• Карта источников и утверждений
• Что означает ответ о возможности
• Границы origin и RP ID
• Ограничения подсказок WebAuthn для конфиденциальности
• Уважительный поток входа
• Практический итог

Смотреть видео

В этом видео на английском языке проверяется, какие ответы страница может прочитать через вызовы возможностей WebAuthn: сначала на локальной лабораторной странице с тремя объявленными наборами возможностей, затем в двух реальных сборках Chrome на Windows и Ubuntu. Учётные данные не создаются, а проверка не устанавливает личность, анонимность, доступ или решение удалённого сайта. Звуковая дорожка на английском языке.

Карта источников и утверждений

• Защищённый контекст и PublicKeyCredential (нормативный/API-источник): справочник MDN по PublicKeyCredential документирует требование защищённого контекста. Рекомендация статьи: считать это условием совместимости, а не доказательством наличия аутентификатора или учётных данных.
• Доступность платформенного аутентификатора (нормативный/API-источник): W3C 5.1.6 и описание метода в MDN определяют проверку доступности, а не наличие учётных данных. Рекомендация статьи: использовать булево значение только для выбора пути с платформенным аутентификатором.
• Условное посредничество (нормативный/API-источник): возможности клиента W3C и описание условного посредничества в MDN описывают индикатор доступности, а не результат входа. Рекомендация статьи: сохранять другой путь входа, если метод отсутствует или недоступен.
• Origin, RP ID и процедура (нормативные правила протокола): правила origin и RP ID W3C ограничивают учётные данные полагающейся стороной, а алгоритмы процедуры требуют запроса, участия пользователя и проверенного ответа. Рекомендация статьи: принимать решения об учётной записи, правах и восстановлении только после проверки ответа на сервере; не выводить их из сигнала возможности.

Что означает ответ о возможности

PublicKeyCredential доступен только в защищённом контексте. Защищённый транспорт нужен для WebAuthn, но не доказывает доступность аутентификатора или учётных данных. Отсутствие API может объясняться небезопасным контекстом, поддержкой браузера или отсутствием необязательного метода, поэтому для каждого случая нужен понятный запасной путь.

WebAuthn Level 3, раздел 5.1.6, определяет isUserVerifyingPlatformAuthenticatorAvailable(). Спецификация говорит, что полагающиеся стороны используют его, чтобы определить, можно ли создать новые учётные данные с помощью платформенного аутентификатора, который проверяет пользователя. Результат является булевым значением, полученным из процедуры клиентской платформы, выявляющей доступные аутентификаторы с проверкой пользователя. Значение true полезно при выборе пути регистрации через платформенный аутентификатор. Оно не называет аутентификатор, не раскрывает конкретный датчик, не подтверждает регистрацию конкретного пользователя и не показывает, что сайт уже зарегистрировал учётные данные.

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

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

К условному посредничеству нужно относиться так же. Спецификация описывает isConditionalMediationAvailable() как индикатор доступности условного посредничества. Он может помочь выбрать интерфейс, но не выполняет вход и не показывает, что passkey доступен для текущей полагающейся стороны. MDN перечисляет его как статический метод PublicKeyCredential и отмечает, что API доступен только в защищённых контекстах поддерживающих браузеров. При отсутствии метода или недоступном результате приложение должно сохранить другой способ входа.

Доступность, проверка пользователя и учётные данные

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

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

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

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

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

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

Границы origin и RP ID

WebAuthn намеренно ограничен границами. Спецификация Level 3 указывает, что операции привязаны к конкретному origin, а полный origin включается и подписывается в объектах аттестации и утверждениях. Каждые учётные данные также привязаны к идентификатору полагающейся стороны, или RP ID. Аутентификатор ограничивает учётные данные, созданные для одного RP ID, операциями, запрошенными этим RP ID.

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

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

Связанные origin требуют намеренной настройки, а не предположений. Общее название организации или похожее имя хоста сами по себе не создают отношения между учётными данными. Команды, управляющие несколькими сайтами, должны определить политику RP ID и origin до запуска потока passkey, проверить её на поддерживаемых доменах и описать поведение запасного пути, когда такое отношение не применяется.

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

Ограничения подсказок WebAuthn для конфиденциальности

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

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

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

Доступность и восстановление зависят от того же различия. Некоторые пользователи применяют внешние аутентификаторы, общие устройства, вспомогательные технологии или пути восстановления учётной записи, не похожие на обычный поток платформенного аутентификатора. Результат проверки возможности не должен удалять нужные им варианты. Сосредоточьте подписи на предлагаемом действии, не делайте предположений об устройстве пользователя и оставьте возможность выйти из потока без потери прогресса. Это делает экран входа полезнее даже при полной поддержке WebAuthn.

Точная терминология полезна и командам поддержки. В отчёте можно сказать, что вариант passkey был предложен, пользователь его отменил или сервер не проверил утверждение. Нельзя говорить, что у человека нет биометрического оборудования или что браузер однозначно относится к определённой среде на основании одного результата возможности. Узкие описания сохраняют полезный контекст диагностики и не превращают состояние протокола в утверждение о личности.

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

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

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

Для пользователя полезны конкретные вопросы: объясняет ли сайт назначение варианта passkey? Может ли пользователь выбрать другой способ входа? Запрашивает ли сайт учётные данные только после выбора этого пути? Хранит ли сайт только сведения, необходимые для безопасной работы учётной записи? Эти вопросы практичнее, чем попытка вывести точную личность или оборудование из подсказки о возможности.

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

Уважительный поток входа

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

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

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

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

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

BotBrowser документирует управляемые профилем клиентские возможности WebAuthn. Если вы проводите разрешённое тестирование конфиденциальности или совместимости, это позволяет вам повторять документированную конфигурацию браузера и проверять, что ваша страница входа по-прежнему предлагает запасной путь, когда варианты passkey отличаются. BotBrowser не может ни доказать, ни создать физический аутентификатор, регистрацию учётных данных или подтверждённый вход, а также не управляет правилами origin и RP ID вашей доверяющей стороны, проверкой на сервере и политикой хранения данных. Сопоставьте поддерживаемую конфигурацию с открытыми определениями WebAuthn и собственным потоком учётной записи. Руководство по управлению профилями содержит общие рекомендации по управлению профилями без превращения настройки профиля в утверждение о личности.

Источники

• W3C Web Authentication: WebAuthn Level 3: раздел 5.1.6 определяет метод проверки доступности платформенного аутентификатора с проверкой пользователя; раздел 5.1.7 определяет возможности клиента; раздел 5.1 и модель безопасности описывают защищённые контексты, origin, ответы и область RP ID.
• MDN: Web Authentication API: обзор регистрации, аутентификации и passkeys для браузера.
• MDN: PublicKeyCredential: сведения о защищённом контексте и статических методах PublicKeyCredential, включая условное посредничество и доступность платформенного аутентификатора с проверкой пользователя.

Практический итог

Решите, что каждая подсказка вправе изменить, прежде чем подключать её к экрану. Значение true от isUserVerifyingPlatformAuthenticatorAvailable() позволяет выделить кнопку passkey, значение true от isConditionalMediationAvailable() включает условный путь navigator.credentials.get(), и оба оставляют на месте пароль и восстановление доступа. Ни одно из них не оправдывает скрытие пути, запись отметки в учётную запись или вывод, что восстановление больше не нужно.

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

Если в выпуск входит управляемая профилем конфигурация возможностей клиента, повторите ту же страницу на ней и убедитесь, что запасной путь по-прежнему появляется при другой поддержке passkeys. Запишите сборку браузера, ревизию профиля, origin и RP ID рядом с этим результатом и описывайте его как одну поддерживаемую конфигурацию, а не как утверждение о любом аутентификаторе посетителя.