Pass-ta-key: что на самом деле означает атака на Google Passkeys

Неужели passkeys всё-таки небезопасны? Именно этот вопрос поднимает Pass-ta-key.

Palo Alto Networks Unit 42 описывает три цепочки атак, с помощью которых вредоносное ПО может злоупотреблять синхронизированными через Google ключами доступа, обходить проверку пользователя и, в самом тяжёлом сценарии, извлекать все закрытые ключи passkeys учётной записи.

Ни один из трёх методов не взламывает WebAuthn, FIDO2 или используемую криптографию с открытым ключом. Для каждого из них необходимо, чтобы на Windows-компьютере жертвы уже работало вредоносное ПО. Это существенное ограничение.

Но сводить анализ к фразе «на скомпрометированном конечном устройстве и так всё потеряно» слишком просто. Вариант Golden Pass-ta-key должен превращать локальное проникновение в постоянно пригодный к использованию и экспорту пакет всех синхронизированных passkeys. Его последствия выходят за рамки кражи одной браузерной сессии.

Краткий вывод

Да, это новая и самостоятельная тема в области безопасности. Но она не даёт оснований отказываться от passkeys или снова переходить исключительно на пароли.

Правильная оценка выглядит так:

• Протокол остаётся надёжным: Origin Binding, Challenge-Response и асимметричная криптография не взломаны.
• Атакуется конкретная реализация: речь о сочетании Google Password Manager, Chrome, Windows и TPM, которое исследовала Unit 42.
• Конечное устройство уже должно быть скомпрометировано: это не атака, которую произвольный сайт из интернета может провести против чистого компьютера.
• Потенциальный ущерб всё равно значителен: варианты простираются от незаметно созданного утверждения для входа до извлечения закрытых ключей всех синхронизированных passkeys.
• Синхронизированные и привязанные к устройству passkeys имеют разные профили риска: и те и другие являются passkeys, но обеспечивают не один и тот же уровень безопасности.
• Пароли остаются худшей альтернативой: их дополнительно можно выманить фишингом, использовать повторно, угадать или украсть из серверной базы данных.

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

Технические границы и доказательная база

Подтверждённые данные по состоянию на 31 августа 2026 года включают описанные Unit 42 цепочки атак, спецификацию WebAuthn, документацию Google по passkeys, общедоступную задачу Chromium и актуальные требования NIST к синхронизируемым аутентификаторам. Для оценки поверхности атаки также важны Pass-the-Passkey от SpecterOps, CVE-2026-34348, понижение FIDO от Proofpoint и технические выводы Expel и SquareX.

Исследование было опубликовано 3 августа и обновлено Unit 42 14 августа. Оно явно относится к Google Password Manager в Chrome под Windows на устройствах с Trusted Platform Module. У других браузеров, операционных систем и провайдеров passkeys могут существовать похожие архитектурные вопросы, однако эти три атаки на них не демонстрировались.

Для данных конкретных методов не зафиксирована активная кампания атак в реальных условиях. Текущая доказательная база состоит из исследования, Proof of Concept и Responsible Disclosure. Для оценки риска это важно: техническая демонстрация ещё не означает массовую эксплуатацию.

Что на самом деле защищает passkey

Passkey не является особенно длинным паролем. Это ключ доступа WebAuthn на основе асимметричной криптографии.

При регистрации аутентификатор создаёт пару ключей:

private key -> remains with the authenticator
public key  -> is registered with the online service

Онлайн-сервис, называемый в WebAuthn «Relying Party», сохраняет открытый ключ вместе с Credential-ID и учётной записью пользователя. При следующем входе сервис отправляет новую случайную Challenge. Аутентификатор подписывает данные, связывающие, помимо прочего, эту Challenge с контекстом вызывающего сайта. Сервер проверяет подпись сохранённым открытым ключом.

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

Не менее важна привязка к Relying-Party-ID и Web-Origin. Passkey для example.com не создаст на обманчиво похожем фишинговом домене утверждение, действительное для example.com. У пользователя нет секрета, который можно ввести на поддельном сайте или продиктовать злоумышленнику по телефону.

Именно это означает устойчивость к фишингу. NIST определяет термин узко: мошеннический Verifier не должен получить ни секрет аутентификации, ни ответ аутентификации, пригодный для настоящего сервиса. WebAuthn обеспечивает это криптографической привязкой к имени Verifier.

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

Разница между User Presence и User Verification

Для понимания трёх атак нужно различать два сигнала WebAuthn:

• User Presence, UP: пользователь выполнил действие, подтверждающее присутствие, например коснулся Security Key или подтвердил диалог.
• User Verification, UV: аутентификатор локально проверил пользователя, например с помощью Windows Hello, PIN-кода или биометрии.

Утверждение WebAuthn содержит эти результаты в виде флагов в authenticatorData. Сервер не должен доверять лишь тому, что он запросил при начале входа. Если он требует userVerification: "required", то в ответе обязан также проверить, действительно ли установлен UV-флаг.

Эта единственная контрольная точка имеет большое значение. Unit 42 не смогла успешно завершить простую атаку Pass-ta-key против GitHub из-за отсутствия необходимой User Verification. На eBay вход сначала всё же удался, хотя User Verification была запрошена. После уведомления eBay исправила серверную проверку.

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

Почему синхронизированные passkeys создают дополнительную область доверия

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

Это не незначительное отличие реализации. Синхронизация расширяет систему:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

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

Поэтому NIST явно рассматривает синхронизируемые аутентификаторы как отдельную категорию. Они могут подходить для сценариев вплоть до Authentication Assurance Level 2. Для AAL3 NIST, напротив, требует неэкспортируемые ключи в защищённой аппаратными средствами среде или отдельном аутентификаторе. Это не означает, что синхронизированные passkeys слабы. Это означает, что удобство и переносимость ключей формируют иную модель гарантий.

Именно эту дополнительную область доверия атакует Pass-ta-key.

Точные границы исследования

Unit 42 называет несколько предпосылок, которые часто терялись в заголовках:

• затронутыми синхронизированными passkeys управляет Google Password Manager;
• Chrome работает в Windows;
• устройство оснащено TPM;
• вредоносное ПО уже работает в пользовательском контексте жертвы;
• пользователь настроен в соответствующей среде Chrome и Google;
• для отдельных вариантов вредоносная программа должна читать локальные данные Chrome, изменять файлы состояния или исследовать память процесса Chrome.

Универсальная атака на любой passkey не была показана. Не демонстрировалось и то, что удалённый злоумышленник без предварительной компрометации конечного устройства может просто извлечь ключ WebAuthn из TPM.

Поэтому формулировка «passkeys взломаны» неверна. Точнее будет так: Unit 42 продемонстрировала три цепочки атак на механизмы доверия, Onboarding и Recovery синхронизированных Google Passkeys на скомпрометированных Windows-устройствах.

Нулевая фаза: локальная карта passkeys

До начала любого из трёх вариантов вредоносная программа, по данным Unit 42, считывает локальную базу синхронизации Chrome. В ней находятся записи WebauthnCredentialSpecifics. Они содержат, среди прочего, сведения о Relying Party, имена пользователей, Credential-ID и зашифрованный материал закрытых ключей.

Исследование указывает следующий путь:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

В тесте для доступа к этим данным не потребовались повышенные привилегии. Материал закрытого ключа не хранится напрямую в открытом виде, однако метаданные дают вредоносной программе список целей: для каких сервисов существуют passkeys, к каким учётным записям они относятся и к какому Credential-ID следует обратиться.

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

Pass-ta-key: действительное утверждение без участия пользователя

Первый вариант злоупотребляет ключом устройства, которым Chrome подтверждает Google Cloud Authenticator идентичность Windows-устройства.

Для этого Chrome создаёт поддерживаемый TPM Identity Key. Unit 42 описывает, что Chrome не хранит закрытый ключ как обычный ключ в открытом виде. Вместо этого Chrome экспортирует его через Windows CNG в виде NCRYPT_OPAQUE_KEY_BLOB. TPM защищает этот Blob так, чтобы его можно было повторно импортировать для криптографических операций на том же физическом TPM.

С криптографической точки зрения это разумно, но автоматически проблему авторизации не решает. Согласно исследованию, вредоносная программа в обычном пользовательском контексте могла прочитать сохранённый wrapped_identity_private_key или получить его из памяти Chrome и вызвать штатные функции Windows CNG. Затем TPM выполняет подпись, поскольку запрос технически поступает с правильного устройства. Он не знает, кто вызвал API: Chrome или вредоносная программа.

Упрощённо процесс выглядит так:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

В этом варианте файл закрытого ключа passkey необязательно экспортируется. Вредоносная программа использует скомпрометированное устройство и Google Cloud Authenticator как сервис подписи.

Естественным ограничителем служит UV-флаг. Identity Key подтверждает владение устройством, но не успешную проверку PIN-кода или биометрии. Корректно реализованный сервис, который обязательно требует User Verification и проверяет результат, должен отклонить утверждение с UV = 0.

Это не делает вариант безобидным. Многие сервисы из соображений совместимости или UX настраивают User Verification лишь как preferred. Другие запрашивают её, но неправильно проверяют ответ. В таких случаях вход, задуманный как многофакторный, фактически сводится к одному фактору: доступу к идентичности устройства.

Silver Pass-ta-key: злоумышленник регистрирует собственную UV-идентичность

Silver Pass-ta-key обходит описанное ограничение. Злоумышленник не пытается взломать Windows Hello или биометрию жертвы. Он добивается того, чтобы Cloud Authenticator в дальнейшем принимал его собственный ключ как действительное подтверждение User Verification.

Исходной точкой служит процесс Re-Onboarding. Согласно исследованию, вредоносная программа может заставить Cloud Authenticator забыть существующее состояние устройства или локально удалить файл passkey_enclave_state. При следующей операции с passkey Chrome должен зарегистрировать устройство заново.

В Windows ключ User Verification необязательно создаётся на первом шаге. Chrome может сначала применить Recovery-PIN Google Password Manager и установить состояние uv_key_pending. Сам UV-Key появляется при следующем использовании passkey. Этот промежуточный этап, оптимизированный для удобства пользователя, открывает окно возможностей.

Для подготовки жертва должна пройти неожиданно инициированный шаг Recovery или Re-Onboarding и ввести GPM-PIN. Вредоносной программе не нужно красть PIN. Она использует появившееся после этого состояние uv_key_pending. Последующие злоумышленные входы могут выполняться без дальнейшего участия пользователя и даже без доступности его устройства.

В собственной среде злоумышленник создаёт пару ключей и отправляет открытый ключ как новый UV-Key. По результатам Unit 42, Google Cloud Authenticator при этом не проверял, действительно ли новый ключ происходит из доверенного оборудования. Система сохранила ключ злоумышленника рядом с легитимной идентичностью устройства.

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

Общедоступная задача Chromium описывает это поведение как «GPM Passkeys Are Vulnerable to User Verification Key Abuse». На момент моей проверки она была отмечена как WAI. Независимо от внутренней оценки случай показывает важное архитектурное правило: процесс Recovery или Onboarding, привязывающий новые доверенные ключи, сам является критически важной процедурой аутентификации.

Golden Pass-ta-key: Cloud-Sync превращается в экспортируемый ключевой материал

Golden Pass-ta-key является самым тяжёлым вариантом. Его цель состоит в получении Security Domain Secret, сокращённо SDS. Этот 32-байтовый секрет защищает синхронизированные закрытые ключи passkeys учётной записи Google Password Manager.

Упрощённо архитектурное обещание звучит так: у клиента есть только зашифрованный wrapped_secret. Расшифрование выполняется в Cloud Authenticator с помощью ключа конкретного устройства. Поэтому даже вредоносная программа на клиенте не должна просто получать закрытые ключи passkeys.

Однако при Onboarding и Recovery инфраструктура синхронизации должна вновь принимать устройства в Security Domain. Unit 42 обнаружила, что Chrome при этом получает SDS в доступной клиенту форме. Сначала секрет даже появлялся в диагностическом журнале FIDO Chrome. После уведомления Google убрала эту запись из журнала. Но в ходе процесса SDS по-прежнему попадает в память процесса Chrome.

Поэтому Golden Pass-ta-key не является произвольным дампом памяти в любой момент. Сначала вредоносная программа принудительно запускает критически важный путь Onboarding или Recovery и должна поймать момент, когда SDS присутствует в процессе Chrome. Это усложняет атаку, но после успешного извлечения не меняет масштаб возможностей, которые даёт похищенный секрет.

Цепочка атаки объединяет несколько шагов:

1. Вредоносная программа принудительно запускает новый Onboarding.
2. Она ждёт повторного создания или изменения локального состояния Enclave.
3. В подходящий момент считывает память процесса Chrome и ищет SDS.
4. Объединяет SDS с ранее прочитанными записями синхронизации.
5. Расшифровывает содержащиеся в них закрытые ключи passkeys.
6. После этого собственный аутентификатор, не зависящий от устройства жертвы, может создавать действительные утверждения.

Здесь проходит качественная граница с украденным Session-Cookie. Сессия может истечь или быть отозвана на сервере. Golden Pass-ta-key, напротив, должна экспортировать закрытые ключи всех уже синхронизированных passkeys. Unit 42 также пишет, что тот же SDS защищает синхронизированные passkeys, созданные в будущем, а в исследованной архитектуре не было заметной возможности ротации или отзыва SDS.

Это утверждение описывает состояние исследованной реализации Google. Оно не доказывает, что каждый провайдер passkeys использует такую же схему Master Key или что Google никогда не сможет изменить архитектуру.

Почему локальное вредоносное ПО не делает атаку несущественной

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

Сам класс атак тоже не нов. Кража секретов или активных сессий из скомпрометированного менеджера паролей и браузера уже много лет входит в инструментарий инфостилеров. Pass-ta-key не превращает существующую компрометацию конечного устройства в магическую удалённую атаку.

Но считать атаку из-за этого несущественной также неверно. Исследование даёт конкретные, зависящие от реализации сведения, которые ранее не были очевидны:

• непривилегированный процесс мог использовать привязанный к TPM ключ устройства Chrome для подписи;
• граница между владением устройством и проверкой пользователя зависела у Relying Parties от корректной обработки UV-флага;
• состояние Re-Onboarding позволяло зарегистрировать контролируемый злоумышленником UV-Key;
• центральный секрет синхронизации сначала появлялся в журнале, а затем, согласно исследованию, оставался доступным в памяти процесса;
• самый тяжёлый путь делал синхронизированные закрытые ключи пригодными для повторного использования вне исходного устройства;
• у синхронизированных passkeys часто нет классического счётчика подписей как надёжного признака клонирования, поскольку несколько легитимных устройств используют один Credential.

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

Pass-ta-key как часть новой поверхности атаки

Pass-ta-key появилась не в изоляции. Исследования 2025 и 2026 годов показывают несколько способов, которыми злоумышленники могут ослабить защиту passkey, не взламывая его закрытый ключ математически.

При злоупотреблении Sync и Recovery Pass-ta-key требует уже работающего вредоносного ПО на Windows-устройстве. Pass-the-Passkey, напротив, объединяет доступ к записанному в журнал утверждению с серверной уязвимостью повторного воспроизведения. Для понижения FIDO достаточно дополнительного активного и уязвимого для фишинга способа входа, тогда как Passkeys Pwned предполагает вредоносное браузерное расширение или выполнение Script в контексте браузера. Наконец, инфостилеры атакуют не сам passkey, а крадут уже аутентифицированную сессию из скомпрометированного браузера или конечного устройства.

Ни один из этих путей не взламывает криптографию с открытым ключом. Их объединяет атака на один из уровней доверия вокруг WebAuthn: Sync и Recovery, серверную проверку, браузер или сессию после входа.

Это различие не придирка к словам. Взлом протокола принципиально поставил бы под сомнение все соответствующие стандарту реализации. Описанные случаи, напротив, требуют разных контрмер на уровне конечных устройств, браузера, Identity и сервера.

Pass-the-Passkey: когда действительное утверждение можно использовать повторно

К Black Hat USA 2026 SpecterOps выявила три уязвимости в Windows 11 и Microsoft Entra ID и более 20 производных техник атак. Самая важная цепочка начиналась в неожиданном месте: Windows записывала полные утверждения WebAuthn в журнал событий Microsoft-Windows-WebAuthN/Operational.

Такое утверждение содержит, среди прочего, Credential-ID, Challenge, данные аутентификатора и подпись. Оно не является закрытым ключом и при корректной реализации Verifier должно срабатывать только один раз и только в соответствующей сессии входа. Однако SpecterOps обнаружила, что Entra ID в течение ограниченного периода повторно принимала записанные утверждения. Так совпали две ошибки:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

Часть проблемы на стороне Windows получила идентификатор CVE-2026-34348. 14 июля 2026 года Microsoft выпустила обновление, которое сокращает записываемую подпись до нескольких байтов и тем самым устраняет источник Replay. Дополнительно для некоторых FIDO2 Security Keys была введена серверная проверка счётчиков подписей. Однако такие счётчики не являются универсальной защитой. Некоторые платформенные и синхронизированные Credentials постоянно возвращают ноль или совместно используют состояние на нескольких устройствах.

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

Другая техника атаки затрагивает Parent-Window-Handle Windows WebAuthn API. Локальный процесс может расположить настоящий диалог passkey так, что визуально он будет казаться принадлежащим доверенной программе, например браузеру или почтовому клиенту. Системный интерфейс и здесь настоящий, но вызывающий контекст может вводить в заблуждение. Поэтому пользователи должны относиться к неожиданным запросам passkey и Windows Hello так же, как к неожиданным MFA Push-уведомлениям.

Самый слабый резервный способ определяет реальный уровень безопасности

В 2025 году Proofpoint продемонстрировала понижение FIDO против Microsoft Entra ID. Модифицированный поток Evilginx выдавал себя за браузер без поддержки FIDO. После этого целевая платформа предлагала альтернативные методы входа. Если жертва выбирала SMS, OTP или другой уязвимый для фишинга метод, учётные данные и сессию можно было перехватить в потоке Adversary-in-the-Middle.

Атака не обходит Origin Binding. Она не позволяет церемонии WebAuthn начаться. Это работает только тогда, когда наряду с passkey для учётной записи разрешён более слабый метод. Эксплуатация этого понижения в реальных атаках не задокументирована.

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

Браузер входит в модель безопасности

Под названием Passkeys Pwned SquareX показала, как вредоносное браузерное расширение или выполнение Script в контексте браузера может влиять на вызовы navigator.credentials.create() и navigator.credentials.get(). Особенно важна регистрация: если злоумышленнику удаётся в нужный момент внедрить собственный ключевой материал, пользователь может увидеть настоящий биометрический диалог, тогда как в фоне привязывается Credential под контролем злоумышленника.

Это исследование принадлежит поставщику решений безопасности, и его не следует приравнивать к универсальному браузерному Exploit. Необходимая предпосылка уже серьёзна: расширение или Script-контекст должны суметь встроиться в путь WebAuthn. Тем не менее архитектурный вывод обоснован. Браузерные расширения, Content Scripts и легитимные прокси-функции WebAuthn входят в Trusted Computing Base. Поэтому в управляемых средах списки разрешённых расширений и контроль привилегированных браузерных API относятся к защите Identity, а не только к гигиене браузера.

Passkeys защищают вход, но не обязательно последующую сессию

После успешной аутентификации веб-сервис обычно продолжает работу с Session-Cookie или Token. Если инфостилер может похитить этот артефакт сессии из браузера, а сервер допускает повторное использование с другого устройства, злоумышленнику не нужны ни пароль, ни passkey. Он атакует уже аутентифицированную сессию.

Сегодня это более практичный путь атаки, чем многие из описанных исследовательских Proof of Concept. Passkeys значительно сокращают поверхность атаки до и во время входа. Но они не заменяют безопасное хранение Token, короткую и соразмерную риску продолжительность сессии, повторную аутентификацию для критических действий, отзыв Token и, по возможности, криптографическую привязку ценных сессий к используемому устройству.

Поэтому фраза «MFA была обойдена» при краже сессии часто вводит в заблуждение. MFA была успешно пройдена. Украли уже её результат.

PoisonSeed показывает, как быстро исследование превращается в хайп

В июле 2025 года Expel сначала сообщила о предполагаемой атаке на Cross-Device Authentication с passkeys. Злоумышленник якобы мог передать жертве легитимный QR-код через фишинговую страницу и таким образом удалённо перехватить вход. Через несколько дней Expel публично отозвала основное утверждение и принесла извинения.

Последующий анализ показал, что предусмотренная для Cross-Device Authentication локальная проверка близости не была успешно преодолена. Без необходимой близости процесс истекал, все попытки MFA завершались неудачей, и злоумышленник не получал доступ.

Этот случай особенно полезен для текущей дискуссии. Не всякое правдоподобно звучащее сочетание QR-кода, фишинга и passkey является рабочим обходом FIDO. Качественная коммуникация о безопасности должна различать наблюдаемое присвоение учётной записи, воспроизводимый Proof of Concept, теоретическую атаку и опровергнутую гипотезу.

Моя оценка безопасности

Технический охват Pass-ta-key ограничен. Цепочка атаки подтверждена для Google Password Manager в Chrome на Windows-системах с TPM. Вероятность реализации находится на среднем или низком уровне, поскольку вредоносное ПО уже должно работать локально и, в зависимости от варианта, целенаправленно изменять состояния или память процесса.

Возможные последствия, напротив, высоки или очень высоки. Успешная атака может привести к захвату учётной записи, постоянному удалённому доступу или извлечению нескольких закрытых ключей. Риск для протокола остаётся низким: WebAuthn, Origin Binding и криптография с открытым ключом не взломаны.

Для обычного пользователя синхронизированный passkey, как правило, остаётся безопаснее пароля с SMS-кодом или TOTP. Он исключает фишинг, Credential Stuffing и кражу повторно используемых парольных данных из множества реалистичных путей атак.

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

Это не отказ от синхронизированных passkeys. Это многоуровневая архитектура безопасности.

Что должны проверить операторы веб-сервисов

Главный вывод для Relying Parties не экзотичен. Это корректная проверка WebAuthn.

Серверам следует:

• устанавливать userVerification: "required", когда сценарий действительно требует локальной проверки пользователя;
• обязательно проверять возвращённый UV-флаг в authenticatorData;
• полностью проверять Challenge, Origin, Relying-Party-ID и подпись;
• генерировать каждую Challenge случайным образом, ограничивать её коротким сроком, принимать только один раз и привязывать к конкретной сессии;
• не допускать попадания полных утверждений, подписей и других повторно используемых артефактов аутентификации в журналы;
• регистрировать добавление и удаление passkey, а также Account Recovery как события высокого риска;
• разрешать новые аутентификаторы для привилегированных учётных записей только после строгой повторной аутентификации;
• по возможности фиксировать происхождение и свойства аутентификатора;
• для сценариев повышенной безопасности рассмотреть Attestation и управляемые аутентификаторы;
• включать необычные смены устройств и геолокации, а также новые привязки passkey в телеметрию Identity;
• отзывать сессии после рискованных изменений и повторно аутентифицировать критические действия;
• использовать привязанные к устройству сессии, как только платформа и приложение смогут надёжно их поддерживать.

Проверенная библиотека WebAuthn уменьшает риск неполной самостоятельной реализации, но не освобождает оператора от проверки её конфигурации. Случай eBay показывает, как один непроверенный флаг может снизить задуманный уровень безопасности. Pass-the-Passkey дополнительно показывает, что даже корректная подпись бесполезна, если Challenge и сессия не сопоставлены должным образом.

Что компаниям следует изменить при внедрении passkeys

Проекты passkey часто планируются как проекты IAM. Pass-ta-key показывает, что одновременно это проекты конечных устройств, браузеров и Recovery.

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

Обычные учётные записи могут использовать синхронизированные passkeys на управляемых устройствах в сочетании с защитой конечных точек и Conditional Access. Для чувствительных служебных учётных записей подходят управляемые платформенные аутентификаторы или ограниченные среды синхронизации с более строгой привязкой к устройству. Администраторские, Break-Glass и другие ценные учётные записи должны использовать отдельные привязанные к устройству аппаратные ключи FIDO2, строго контролируемый Recovery и не должны допускать неконтролируемую облачную синхронизацию.

Дополнительно компаниям следует:

• своевременно обновлять Chrome и Windows;
• проверить уровень обновлений безопасности Windows для CVE-2026-34348;
• осознанно разрешать или ограничивать хранение passkeys во встроенном менеджере браузера с помощью Enterprise Policies;
• управлять браузерными расширениями через Allowlist и контролировать привилегированные прокси-функции WebAuthn;
• распространять EDR и Application Control также на пользовательские процессы;
• контролировать доступ к базам синхронизации браузера и дампы памяти процесса Chrome;
• расследовать удаление или неожиданное повторное создание passkey_enclave_state;
• считать повторные или неожиданные запросы Recovery-PIN Google Password Manager предупреждающим сигналом;
• проверять существующие процессы потери устройства и Account Recovery на возможность злоупотребления;
• удалить уязвимые для фишинга резервные способы у привилегированных учётных записей или исключить их политикой Authentication Strength;
• расследовать неожиданные запросы passkey, новые регистрации Credentials и использование WebAuthn необычными процессами;
• вести учёт того, какие критически важные сервисы используют синхронизированные, а какие привязанные к устройству Credentials.

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

Что пользователям следует сделать сейчас

Нет объективных причин профилактически удалять все passkeys и возвращаться к более слабым паролям.

Разумно сделать следующее:

• своевременно обновить Chrome и Windows;
• устанавливать только доверенные программы и браузерные расширения;
• поддерживать активными защиту устройства, Windows Hello и защиту от вредоносного ПО;
• не подтверждать неожиданные диалоги passkey или Windows Hello;
• не подтверждать мимоходом неожиданные запросы Recovery-PIN или Re-Onboarding;
• проверить зарегистрированные устройства и passkeys в Google Password Manager и у важных сервисов;
• рассмотреть отдельный аппаратный Security Key для особо ценных учётных записей;
• не продолжать использовать подозрительное конечное устройство, а изолировать его и передать на исследование.

При конкретных признаках вредоносного ПО, изменённых состояний Chrome или дампа памяти следует исходить из возможной кражи Credentials и сессий. Смены пароля тогда недостаточно. Нужны переустановка или надёжная очистка конечного устройства, отзыв активных сессий, проверка методов Recovery, удаление неизвестных passkeys и повторная регистрация доверенных аутентификаторов.

При возможном инциденте Golden Pass-ta-key необходима особая осторожность. Опубликованные результаты исследования не описывают простой ротации SDS для пользователей. Поэтому нельзя утверждать, что смена PIN-кода или простое повторное создание одного passkey гарантированно решит проблему. Для ценных учётных записей после очистки конечного устройства я бы зарегистрировал новые привязанные к устройству Credentials, удалил старые синхронизированные Credentials и привлёк провайдера или команду Incident Response к восстановлению.

Главный вывод

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

Pass-ta-key показывает следующий уровень. Как только закрытые ключи удобно синхронизируются между устройствами, возникает инфраструктура шифрования ключей, доверия к устройствам и Recovery. В ней могут быть ошибки, даже если базовый протокол WebAuthn корректен.

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

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

Passkeys гораздо надёжнее заперли дверь перед фишингом. Pass-ta-key напоминает, что против злоумышленника, который уже находится внутри, нужна другая защита.

До следующего раза,
Джо

FAQ