Passkeys: Google Password Manager Gets Targeted | CyberCalm

Наталя Зарудня

Від Наталії ЗарудніШеф-редакторШеф-редактор та фундаторка CyberCalm. Більш ніж 10 років досвіду у сфері кібербезпеки та технологічної журналістики. Мої статті присвячені захисту інформації, безпеці мобільних пристроїв, штучному інтелекту та соціальним мережам.Підписуйтесь: 05.08.2026Поділитися11 хвилин на читання

Фахівці з Unit 42 (Palo Alto Networks) описали три методи атак, що дозволяють зловмисному програмному забезпеченню на вже скомпрометованому комп’ютері з Windows зловживати синхронізованими ключами доступу (passkeys) у Google Password Manager. Найпростіший сценарій передбачає, що зловмисник отримує доступ до облікового запису жертви без необхідності введення відбитка пальця, PIN-коду або будь-якої взаємодії з користувачем. Найскладніший випадок полягає у викраденні майстер-ключа та подальшому розшифруванні всіх синхронізованих passkeys. Криптографічні механізми самих ключів доступу дослідниками не були зламані.

Зміст

Що таке passkeys та чому їх вважають більш надійними за паролі
Умови для проведення атак: скомпрометований Windows, Chrome та TPM
Pass-ta-key: імітація довіреного пристрою
Silver Pass-ta-key: підроблений ключ підтвердження ідентичності
Golden Pass-ta-key: викрадення головного ключа
Що це означає для користувачів
Рекомендації щодо виправлень для розробників та сервісів
Чому це важливо для українських користувачів
Що можна зробити вже зараз
Поширені запитання

Звіт під назвою «Pass the Passkey: A Novel Attack Surface in Passwordless Authentication» був опублікований 3 серпня 2026 року. Всі три методи об’єднані під загальною назвою Pass-ta-key і ефективні лише за умови, що зловмисне ПЗ вже виконується на пристрої жертви. Дослідники повідомили про свої знахідки компанії Google та сервісам, яких вони стосуються, перед публікацією звіту.

Що таке passkeys та чому їх вважають більш надійними за паролі

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

Passkeys розглядаються як більш стійке рішення порівняно з традиційними паролями, оскільки їх неможливо вгадати, повторно використати або викрасти шляхом фішингу. Згідно з документацією Google, вони є обліковими даними, які неможливо передати, скопіювати, записати або випадково розкрити третій стороні.

Google додатково посилила цю модель безпеки: приватні ключі генеруються та використовуються в межах ізольованого хмарного середовища (cloud authenticator). Доступ до криптографічних операцій контролюється апаратними ключами, прив’язаними до конкретного пристрою. Саме цю архітектуру й досліджували фахівці.

Умови для проведення атак: скомпрометований Windows, Chrome та TPM

Дослідження зосереджене на Google Password Manager у браузері Chrome на пристроях з операційною системою Windows, оснащених модулем TPM. Кожен із виявлених сценаріїв передбачає, що на комп’ютері жертви вже функціонує зловмисне програмне забезпечення, яке має права звичайного користувача, без адміністраторських привілеїв.

Жоден із запропонованих методів не порушує криптографію WebAuthn. Натомість вони експлуатують проміжні механізми: спосіб зберігання ключів пристрою в Chrome, процес повторної реєстрації після втрати локального стану та перевірку сервісом факту ідентифікації користувача.

Для отримання необхідної інформації не потрібні підвищені права. Chrome зберігає синхронізовані дані passkey у локальній базі даних LevelDB, розташованій у профілі користувача. З цих даних можна дізнатися, на яких сервісах жертва використовує ключі доступу, під якими іменами та які ідентифікатори мають відповідні облікові записи.

Pass-ta-key: імітація довіреного пристрою

Перший метод імітує стандартну роботу браузера Chrome. Програма зберігає ключ ідентифікації пристрою у зашифрованому форматі TPM blob у файлі стану passkey_enclave_state. Шкідливий софт зчитує цей blob і за допомогою стандартних криптографічних інтерфейсів Windows (CNG) змушує TPM підписати запит зловмисника.

Хмарний автентифікатор Google розглядає такий запит як звернення з довіреного комп’ютера жертви та надає у відповідь дійсний підписаний результат. Цього достатньо для входу в обліковий запис — без згоди користувача, біометричних даних чи розблокування пристрою.

Єдине обмеження цього методу: прапорець User Verified (UV) у відповіді має нульове значення. Цей біт підтверджує, що користувач пройшов ідентифікацію за допомогою PIN-коду або біометричних даних. Його призначення описане у специфікації W3C Web Authentication (Level 2), і сервіс, до якого відбувається вхід, має перевіряти цей прапорець.

На практиці перевірку виконують не завжди. Спроба входу в акаунт GitHub не вдалася: сервіс коректно відхилив відповідь без підтвердження користувача. Натомість на eBay атака спрацювала — платформа вимагала перевірку користувача, але не здійснювала перевірку самого прапорця UV, фактично зводячи багатофакторну автентифікацію до одного фактору. Після звернення дослідників eBay усунув цю вразливість.

Silver Pass-ta-key: підроблений ключ підтвердження ідентичності

Другий метод призначений для сервісів, які коректно перевіряють прапорець UV. Замість отримання доступу до легітимного ключа підтвердження, зловмисник змушує систему зареєструвати власний ключ.

Для цього зловмисне програмне забезпечення анулює наявний ключ: надсилає команду про «забуття» пристрою або просто видаляє файл passkey_enclave_state — вбудованих механізмів для запобігання цьому не існує. Під час наступного використання passkey, Chrome ініціює повторну реєстрацію пристрою.

Тут спрацьовує особливість реалізації в Windows: щоб уникнути подвійного запиту PIN-коду для користувача, Chrome відкладає створення ключа підтвердження до наступного використання passkey, залишаючи пристрій у стані очікування. Саме в цей момент зловмисник реєструє власний публічний ключ — хмарний автентифікатор не перевіряє, чи новий ключ походить із захищеного апаратного модуля.

Після цього будь-який підпис, здійснений ключем зловмисника, розглядається як підтвердження того, що користувач розблокував пристрій. Доступ стає багаторазовим: атакувати можна з власного середовища, і комп’ютер жертви для цього вже не потрібен.

Golden Pass-ta-key: викрадення головного ключа

Третій, найскладніший метод, спрямований на отримання security domain secret (SDS) — 32-байтового симетричного майстер-ключа, який використовується для шифрування всіх синхронізованих passkeys облікового запису. За задумом, цей ключ не повинен бути доступним клієнту: на пристрої зберігається лише зашифрована копія, яку може розшифрувати виключно хмарний автентифікатор.

Дослідники виявили, що під час реєстрації пристрою секретний ключ у відкритому вигляді потрапляв до внутрішнього журналу Chrome, доступного за адресою chrome://device-log/FIDO. Після звернення Unit 42, Google видалила його з журналів. Однак, за даними дослідників, SDS продовжує надсилатися клієнту та тимчасово зберігається в пам’яті процесу браузера.

На основі цього будується атака: зловмисник ініціює повторну реєстрацію, відстежує зміни у файлі стану, отримує дамп пам’яті Chrome та витягує SDS. Далі цим ключем розшифровуються локальні записи синхронізованих passkeys, а приватні ключі можна перенести на власну систему для входу від імені жертви.

Найсерйознішим наслідком є довготривалість такого доступу. Викрадений SDS дозволяє розшифрувати не тільки вже існуючі, але й усі майбутні ключі доступу облікового запису. За даними Unit 42, у поточній реалізації Google відсутній механізм зміни або відкликання цього секретного ключа, тому навіть після виявлення зламу немає надійного способу відновлення.

Що це означає для користувачів

Дослідники підкреслюють, що passkeys залишаються значно безпечнішими за паролі. Вони усувають цілі класи загроз, таких як фішинг, повторне використання паролів та їх витоки. Жоден із описаних методів не є ефективним проти користувача, чий пристрій не інфікований.

Однак, висновок дослідження свідчить: passkeys не усувають ризиків, пов’язаних зі зловмисним програмним забезпеченням на кінцевому пристрої. Синхронізований ключ доступу успадковує рівень безпеки найслабшого з пристроїв, між якими він синхронізується. Це властивість самого механізму синхронізації, а не технології passkeys як такої.

Чому це важливо для українських користувачів

Спільним початковим етапом для всіх трьох сценаріїв є наявність інфікованого комп’ютера під керуванням Windows. Для України це не абстрактна умова. У березні-квітні 2026 року CERT-UA зафіксував підвищення інтенсивності кібератак на медичні установи, місцеві органи влади та операторів FPV-дронів. Серед інструментів, що використовувалися, фахівці відзначали CHROMELEVATOR — програму, призначену для викрадення облікових даних саме з веб-браузерів.

Отже, ланка, від якої залежить безпека синхронізованих passkeys, в українському контексті піддається регулярним та цілеспрямованим атакам. Для облікових записів з підвищеними вимогами — банківських, робочих, пов’язаних з обороною або критичною інфраструктурою — доцільніше використовувати апаратний ключ безпеки FIDO2, приватний ключ якого не синхронізується між пристроями.

Що можна зробити вже зараз

Регулярно оновлюйте операційну систему та браузер Chrome, не відкладаючи перезапуск браузера після встановлення оновлень.
Не запускайте виконувані файли з архівів, отриманих електронною поштою або через месенджери, навіть якщо відправник здається знайомим.
Для найважливіших облікових записів використовуйте апаратний ключ безпеки FIDO2 замість синхронізованого passkey.
Будьте уважні, якщо Chrome несподівано запитує PIN-код для відновлення доступу до Google Password Manager під час звичайного входу: такі запити є нормальними під час налаштування нового пристрою, але не для щоденної автентифікації.
Періодично перевіряйте список пристроїв та ключів доступу в налаштуваннях безпеки свого облікового запису Google і видаляйте непотрібні.

Поширені запитання

Чи означає це дослідження, що passkeys є небезпечними?

Ні. Дослідники чітко зазначають, що passkeys залишаються значно надійнішими за паролі й усувають цілі класи атак. Криптографічні механізми ключів доступу не були зламані, а всі описані сценарії вимагають наявності зловмисного ПЗ, яке вже функціонує на пристрої користувача.

Чи стосується це користувачів iPhone та пристроїв на Android?

Дослідження зосереджене на Google Password Manager у браузері Chrome на Windows з модулем TPM. Інші браузери, операційні системи та менеджери облікових даних не тестувалися дослідниками. Тому висновки не слід автоматично поширювати на них, проте не варто вважати їх повністю захищеними лише на цій підставі.

Чи можливо замінити головний ключ, якщо його викрали?

За даними Unit 42, у поточній реалізації Google відсутній механізм ротації або відкликання security domain secret. Це означає, що наявні та майбутні синхронізовані passkeys залишаються захищеними тим самим секретним ключем.

Що робити, якщо Chrome раптом запитує PIN-код відновлення Google Password Manager?

Такий запит є доречним під час налаштування нового пристрою або відновлення доступу. Якщо він з’являється під час звичайного входу за допомогою passkey, варто перевірити пристрій на наявність шкідливого ПЗ та переглянути список зареєстрованих пристроїв у вашому обліковому записі Google.

Привіт
Раді знайомству!

Ми не надсилаємо спам! Детальнішу інформацію ви знайдете в нашій політиці конфіденційності.

Перевірте свою електронну пошту або папку зі спамом, щоб підтвердити підписку.

ТЕГИ:GoogleGoogle ChromeWindowsКлючі доступуменеджер паролівПароліПоділитисяFacebookСкопіювати посиланняНадрукуватиВаші думки?Захоплено0Сумно0Смішно0Гнівно0Диво0Попередній запис