Get your free and exclusive +45-page Authentication Analytics Whitepaper
Вернуться к обзору

Ключи доступа в Brave Browser (2026): что работает, а что ломается

Brave в основном следует за Chromium в поддержке ключей доступа, но конфликты с Android, Windows Hello и менеджерами паролей все еще создают проблемы.

Vincent Delitz
Vincent Delitz

Создано: 5 апреля 2026 г.

Обновлено: 3 июля 2026 г.

Ключи доступа в Brave Browser (2026): что работает, а что ломается

Эта страница переведена автоматически. Прочитайте оригинальную версию на английском здесь.

Ключевые факты
  • Код WebAuthn почти не отличается от Chromium. В репозитории brave/brave-core содержится ровно одно видимое изменение, связанное с WebAuthn: переопределение строки, которое переименовывает ярлык Chrome «Incognito» в «Private» в диалоговом окне сохранения ключа доступа. Ни один патч на C++ не затрагивает пути кода WebAuthn.
  • 24 открытых проблемы с ключами доступа/WebAuthn находились в brave/brave-browser по состоянию на апрель 2026 года, судя по поиску проблем в GitHub по словам passkey и WebAuthn. Количество открытых проблем с тегом passkey выросло примерно с 2 в год в 2022-2023 годах до 6 в 2025 году.
  • Кросс-браузерное использование в macOS работает. Ключ доступа, созданный на macOS, может быть сохранен в Связке ключей iCloud (iCloud Keychain) и использоваться в Safari, Chrome и других браузерах на платформе Apple на устройствах с тем же Apple ID.
  • Сборки Android без Google (de-Googled) ломаются. Без сервисов Google Play регистрация и аутентификация ключей доступа часто не работают на Android. Отслеживается в проблеме #45415 (открыта с апреля 2025 года).
  • Windows Hello нельзя полностью подавить. Отключение brave://password-manager/settings не мешает Windows предлагать Hello в качестве платформенного аутентификатора WebAuthn. Отслеживается в проблеме #51858 (открыта в январе 2026 года).
  • Перехват расширений — самая активная регрессия. Проблема #37762, при которой нативный UI ключей доступа переопределяет запросы Bitwarden и 1Password, была открыта в апреле 2024 года и все еще получала отчеты об ошибках 25 марта 2026 года.
  • Обходной путь с флагом web-authentication-new-passkey-ui исчез в версии 146 (Chromium 146), согласно отчету пользователя в brave/brave-browser в проблеме #37762 от 25 марта 2026 года.

1. Введение: поддержка ключей доступа в Brave сегодня#

Поддержка ключей доступа в Brave близка к Chromium на уровне кода, но пользовательский опыт отличается в нескольких важных местах. По состоянию на апрель 2026 года в более широком репозитории brave/brave-browser все еще было 24 открытых проблемы, соответствующих passkey или WebAuthn, в то время как brave/brave-core показывал одну видимую кастомизацию, специфичную для WebAuthn. Основными точками сбоя являются перехват расширений, запросы Windows Hello и потоки Android на устройствах без сервисов Google.

Brave предоставляет ключи доступа через тот же путь кода WebAuthn, что и исходный Chromium, и делегирует хранение учетных данных операционной системе. Эта архитектура делает Brave стандартным на бумаге, но реальное поведение по-прежнему зависит от окружающих систем, таких как расширения менеджеров паролей, Windows Hello и сервисы Google Play. В разделах ниже эти режимы сбоев рассматриваются отдельно, чтобы каждое поведение, специфичное для платформы, можно было понять само по себе.

2. Чем стек WebAuthn в Brave отличается от Chromium?#

Реализация WebAuthn в Brave — это фактически реализация Chromium с одним видимым изменением текста в UI. Репозиторий brave/brave-core содержит единственную кастомизацию, связанную с WebAuthn — переопределение строки, которое переименовывает «Incognito» в «Private» в диалоговом окне сохранения — и никаких патчей на C++, затрагивающих основную логику WebAuthn. Это означает, что Brave наследует стек ключей доступа Chromium, который Google поставляет начиная с Chromium 115 с июня 2023 года.

Это важно по двум причинам. Во-первых, обычные апстрим-слияния означают, что исправления и новые функции WebAuthn обычно поступают без того, чтобы Brave поддерживал глубоко форкнутую реализацию ключей доступа. Вы можете изучить единственное переопределение строки непосредственно в brave/brave-core. В маппингах AAGUID путь браузерного аутентификатора Chromium обычно идентифицируется как b5397666-4885-aa6b-cebf-e52262a439a2 с меткой «Chromium Browser» в нашем списке ссылок. Во-вторых, большинство сообщаемых сбоев — перехват расширений, конфликты автозаполнения и зависимость Android от сервисов Google Play — появляются в смежных системах, таких как автозаполнение, разрешения, Shields или интеграция с Wallet. Они окружают поток WebAuthn, а не заменяют его.

3. Можно ли использовать ключ доступа, созданный на macOS, в Safari на другом устройстве Apple?#

Да, но только если ключ доступа сохранен в Связке ключей iCloud. На macOS Brave использует стек WebAuthn Chromium и может хранить новый ключ доступа либо в платформенном аутентификаторе Apple, либо в другом целевом хранилище, представленном в запросе на создание. Ключ доступа, сохраненный в Связке ключей iCloud, синхронизируется через Apple ID и становится доступным в Safari, Chrome и других браузерах с поддержкой WebAuthn на устройствах Apple, использующих тот же Apple ID.

Как только macOS подтвердит, что Brave разрешен доступ к Связке ключей iCloud, браузер может использовать те же синхронизированные ключи доступа, которые видит Safari. Этот запрос разрешения — практический момент, когда кросс-браузерная переносимость на устройствах Apple становится реальной, а не теоретической.

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

Ключ доступа, сохраненный в хранилище профиля браузера или только в локальном хранилище, не становится автоматически доступным в Safari на другом устройстве Apple. Это различие имеет значение, поскольку синхронизация платформенного аутентификатора на уровне ОС и синхронизация профиля браузера следуют разным правилам. Brave не включает синхронизацию ключей доступа Google Password Manager из Chrome, поэтому только путь Связки ключей iCloud обеспечивает кросс-браузерную переносимость в стиле Apple на устройствах Apple.

4. Почему ключи доступа не работают надежно на Android без сервисов Google Play?#

Менеджер учетных данных (Credential Manager) Android сам по себе не является частью сервисов Google Play. На Android 14 и более новых версиях Chromium может использовать системный путь Credential Manager, в то время как старые версии Android больше полагаются на слой FIDO2, поддерживаемый сервисами Google Play. На практике Brave по-прежнему наследует сбой, задокументированный в проблеме #45415: в GrapheneOS, CalyxOS, /e/OS и других сборках Android без Google и необходимого пути сервисов Play регистрация и аутентификация ключей доступа могут прерываться по таймауту. По состоянию на апрель 2026 года это оставалось открытым пробелом совместимости для пользователей Android, ориентированных на конфиденциальность.

Это поведение задокументировано в brave/brave-browser issue #45415, открытой в апреле 2025 года и все еще открытой год спустя. Документация Google Credential Manager отличает API Credential Manager от необязательной зависимости аутентификации Play Services, используемой в старых версиях Android, а более широкое руководство по Android отмечает, что Android 14+ может работать с включенными менеджерами паролей. В треде также отмечается, что этот же режим сбоя влияет на браузеры на базе Chromium в целом, в то время как браузеры на базе Firefox не подвержены этой проблеме в такой же степени. Исходный автор отчета указал, что GrapheneOS исправила эту зависимость в своем собственном форке Chromium, Vanadium, поэтому исправление на более низком уровне технически выглядит возможным — просто оно еще не произошло.

Несколько пользователей независимо подтвердили это поведение в этом же треде. Один особенно чистый тест в декабре 2025 года использовал одно и то же устройство с двумя профилями: ключи доступа работали в Brave только в профиле с включенными сервисами Play, тогда как Vanadium и Cromite работали в обоих. По состоянию на апрель 2026 года ни один мейнтейнер Brave не ответил в треде. Для аудитории Brave на Android, ориентированной на конфиденциальность — в которую входит непропорционально большое количество пользователей систем без Google — это оставляет очень заметный пробел. Firefox на Android использует свой собственный стек WebAuthn и не зависит от сервисов Play таким же образом. Сегодня практический обходной путь — использовать Firefox для потоков ключей доступа на Android без сервисов Play или использовать аппаратный ключ безопасности с совместимым клиентом. Более подробную информацию о сбоях на Android см. в разделе ошибки ключей доступа в нативных приложениях. Подробную информацию о сервисах Google Play и Credential Manager см. в разделе коды ошибок ключей доступа Android и сервисов Google Play.

5. Почему запросы ключей доступа Windows Hello появляются даже тогда, когда я их отключаю?#

Отключение настройки Brave «предлагать сохранять ключи доступа» не мешает появлению Windows Hello во время потоков WebAuthn. Как только сайт вызывает WebAuthn и Windows Hello зарегистрирован, Windows рекламирует Hello как платформенный аутентификатор, и Brave не предоставляет пользователю элемент управления, который блокирует его. По состоянию на январь 2026 года проблема подавления Windows Hello оставалась нерешенной для пользователей, которые хотели использовать Hello для разблокировки устройства, но не для ключей доступа.

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

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

Сегодня единственный надежный способ подавить эти запросы — полностью отключить регистрацию Windows Hello, что, очевидно, противоречит тому, как большинство людей хотят разблокировать свои устройства. Edge ведет себя иначе, поскольку он более тесно интегрирован с уровнем управления учетными данными Windows и предоставляет элементы управления, которых в настоящее время нет в форках Chromium. Для более широкого обзора поведения ключей доступа в Windows см. раздел Ключи доступа в Windows 11.

6. Следует ли хранить ключи доступа в нативном хранилище или в менеджере паролей?#

Нативное хранение ключей доступа — это самый простой вариант в рамках одной экосистемы, в то время как расширения менеджеров паролей остаются единственным широко применимым кроссплатформенным уровнем синхронизации. Связка ключей iCloud хорошо работает на устройствах Apple, Windows Hello работает на Windows, а хранилища на базе расширений, такие как 1Password или Bitwarden, по-прежнему являются единственным реалистичным вариантом для пользователей, которые хотят, чтобы ключи доступа были изначально доступны в Windows, macOS, Linux и Android. Кросс-устройственная аутентификация (CDA или гибридный транспорт через QR-код и Bluetooth) по-прежнему может связывать устройства во время входа, но она не синхронизирует сами учетные данные и не делает их локально доступными везде по умолчанию. Компромисс заключается в надежности: нативные потоки проще, потоки расширений более переносимы, а CDA лучше всего понимать как резервный путь, а не как стратегию хранения.

Решение в основном сводится к трем вещам: сколько платформ вы используете, насколько вы доверяете потокам расширений и где вы уже храните свои учетные данные. Если вы в основном остаетесь внутри одной экосистемы ОС — все устройства Apple или все устройства Windows — путь нативного платформенного аутентификатора является самым чистым вариантом. В этой установке Brave ведет себя во многом как Chrome или Safari. Если вам нужно, чтобы ключи доступа следовали за вами через Windows, macOS, Linux и Android, стороннее расширение менеджера паролей, такое как 1Password, Bitwarden, Dashlane или Proton Pass, по-прежнему является единственным широко работоспособным уровнем синхронизации.

Сложность заключается в том, что с апреля 2024 года продолжают поступать сообщения о том, что нативный UI ключей доступа периодически перехватывает потоки, управляемые расширениями. Пользователи в проблеме #37762 описывают появление диалоговых окон аутентификации ОС, даже если учетные данные должны принадлежать Bitwarden или 1Password. К марту 2026 года старый обходной путь — отключение brave://flags/#web-authentication-new-passkey-ui — больше не был доступен, поскольку флаг был удален в версии 146.

Место храненияКросс-ОС синхронизацияКросс-браузерное использованиеСредство восстановленияИзвестный риск
Связка ключей iCloudТолько AppleБраузеры AppleApple IDНет
Windows HelloНет (привязано к устройству)То же устройство WindowsРазблокировка устройства / PINДиалоговое окно Hello нельзя отключить
Менеджер паролей GoogleТам, где доступен GPMChrome + поверхности AndroidУчетная запись GoogleНе представлено в профилях Brave здесь
1Password / BitwardenПолнаяПолное (расширение)Учетная запись хранилищаПериодический нативный перехват
Аппаратный ключ безопасностиПривязано к устройствуЛюбой браузерФизическое владениеНет

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

7. О каких болевых точках ключей доступа сообщают пользователи в 2026 году?#

Открытые проблемы Brave с ключами доступа в 2026 году группируются вокруг трех повторяющихся тем: перехват расширений, сбои Android на устройствах без сервисов Google и проблемы с аппаратными ключами безопасности на десктопах. По состоянию на апрель 2026 года в более широком репозитории все еще было 24 открытые проблемы, соответствующие webauthn или passkey, что говорит о том, что трения сконцентрированы, а не случайны.

Самый активный кластер — это перехват расширений, где нативный UI ключей доступа может переопределять запросы 1Password, Bitwarden или Dashlane. Совместимость Android без сервисов Google Play — вторая повторяющаяся проблема, а обнаружение ключей безопасности на десктопе — третья. Темы проблем, на которые чаще всего ссылаются здесь: #37762, #50561, #45415, #15650, #43043, #34441, #33237 и #51858. Активные обсуждения указывают в одном направлении, не требуя множества прямых цитат.

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

8. Заключение#

История с ключами доступа в Brave выглядит чистой на уровне кода и запутанной на уровне пользовательского опыта. Путь WebAuthn фактически является путем Chromium с единственным переопределением строки, подтверждающим, насколько близко реализация держится к апстриму. На платформах Apple переносимость ключей доступа работает именно так, как ожидают пользователи, поскольку учетными данными владеет Связка ключей iCloud. Реальные трения кроются в другом: перехват расширений (#37762), подавление Windows Hello (#51858) и зависимость Android от сервисов Google Play (#45415). Пока эти проблемы не будут решены, разработчикам следует тестировать Brave отдельно, а не предполагать паритет с Chrome, а пользователям следует иметь надежный резервный вариант — в идеале аппаратный ключ безопасности — для важных учетных записей.

9. О Corbado#

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

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

10.1 Можно ли использовать ключ доступа, созданный в Brave на macOS, в Safari на другом устройстве Apple?#

Да, но только если Brave сохраняет ключ доступа в Связку ключей iCloud. На macOS Brave использует стек WebAuthn Chromium и может хранить новый ключ доступа в Связке ключей iCloud или в другом целевом хранилище, показанном в запросе на создание. Ключ доступа, сохраненный в Связке ключей iCloud, синхронизируется через Apple ID и становится доступным в Safari, Chrome и других браузерах на устройствах Apple, использующих тот же Apple ID. Ключ доступа, сохраненный в хранилище профиля браузера или только локальном хранилище, не становится автоматически доступным в Safari на другом устройстве Apple.

10.2 Почему ключи доступа не работают в Brave на Android без сервисов Google Play?#

Brave на Android может давать сбои без сервисов Google Play, но причина более конкретна, чем «Менеджер учетных данных — часть сервисов Play». Credential Manager Android — это системный API и Jetpack API, в то время как старые версии Android больше полагаются на слой FIDO2, поддерживаемый сервисами Google Play. На практике Brave по-прежнему наследует сбой, задокументированный в проблеме brave/brave-browser #45415: в GrapheneOS, CalyxOS или других сборках Android без Google и необходимого пути сервисов Play диалоговое окно ключа доступа никогда не открывается, а регистрация или аутентификация прерывается по таймауту.

Более подробную информацию о сбоях в Android см. в разделе ошибки ключей доступа в нативных приложениях. Подробную информацию о сервисах Google Play и Credential Manager см. в разделе коды ошибок ключей доступа Android и сервисов Google Play.

10.3 Синхронизирует ли Brave ключи доступа между устройствами так же, как Chrome?#

Нет. Brave не предоставляет эквивалента синхронизации ключей доступа профиля браузера Chrome через Менеджер паролей Google. Ключи доступа, созданные в Brave, хранятся в базовом платформенном аутентификаторе ОС — Связке ключей iCloud на Apple, Windows Hello на Windows и Android Credential Manager на Android — и синхронизируются только через эту учетную запись ОС. Если вам нужна последовательная синхронизация между устройствами, вы полагаетесь на поставщика ОС или на стороннее расширение менеджера паролей.

10.4 Почему Brave запрашивает ключи доступа Windows Hello, даже когда я отключаю параметры ключей доступа в настройках?#

Переключатель brave://password-manager/settings в Brave контролирует только то, предлагает ли Brave сохранять ключи доступа сам. Это не мешает Windows рекламировать Windows Hello как платформенный аутентификатор WebAuthn для страницы. Сайт вызывает WebAuthn, Windows представляет Hello, и у Brave нет встроенного в браузер переключателя для подавления диалогового окна ОС. Это поведение отслеживается в проблеме brave/brave-browser #51858.

10.5 Следует ли мне хранить ключи доступа в нативном потоке Brave или в моем менеджере паролей?#

Используйте нативный поток ОС Brave (Связку ключей iCloud или Менеджер паролей Google через платформу), если вы остаетесь внутри одной экосистемы и хотите минимизировать количество движущихся частей. Используйте стороннее расширение менеджера паролей, такое как 1Password или Bitwarden, если вам нужно, чтобы ключи доступа последовательно следовали за вами на Windows, macOS, Linux и Android, или если вы уже храните свои секреты там. С 2024 года нативный UI Brave неоднократно перехватывал потоки ключей доступа расширений, поэтому стоит проверить, что расширение все еще владеет запросом.

10.6 Сколько в настоящее время открыто проблем с ключами доступа и WebAuthn в репозитории brave/brave-browser для поведения ключей доступа Brave?#

По состоянию на апрель 2026 года в brave/brave-browser было 24 открытые проблемы, соответствующие запросам passkey или WebAuthn. Количество открытых проблем с тегом passkey выросло примерно с 2 в год в 2022-2023 годах до 6 в 2025 году. Для Brave доминирующими темами являются перехват расширений на десктопах, подавление Windows Hello и зависимость от сервисов Google Play в Android.

Corbado

О Corbado

Corbado — это Authentication Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey

Посмотрите, как Corbado вписывается во внедрение passkeys и текущий стек аутентификации.

Открыть Console

Поделиться статьей


LinkedInTwitterFacebook