Passkeys: Google Password Managerin hyökkäykset | 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 блоку в файлі стану passkey_enclave_state. Шкідлива програма зчитує цей блок і через стандартні криптографічні інтерфейси Windows (CNG) змушує TPM підписати запит зловмисника.

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

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

На практиці перевірка виконується не завжди. Спроба входу в обліковий запис GitHub виявилася невдалою: сервіс коректно відхилив відповідь без підтвердження користувача. Однак на eBay атака спрацювала — платформа вимагала підтвердження користувача, але не перевіряла сам прапорець, фактично зводячи багатофакторну автентифікацію до одного фактора. Після звернення дослідників 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. Google усунула його з журналів після звернення Unit 42, проте, за даними дослідників, SDS все ще надсилається клієнту та тимчасово зберігається в пам’яті процесу браузера.

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

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

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

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

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

Що радять виправити розробникам і сервісам

Сервісам — вимагати параметр userVerification зі значенням required і обов’язково перевіряти прапорець UV у кожній відповіді автентифікатора.
Менеджерам облікових даних — перевіряти походження та атестацію нових ключів пристрою, а не приймати довільні ключі.
Посилити процедури відновлення та повторної реєстрації пристроїв, зокрема відслідковувати повторні запуски цих сценаріїв після видалення або зміни локальних файлів стану.
Не передавати головний ключ на бік клієнта — ні в журнали, ні в пам’ять процесу.
Обмежити доступ до локальних даних passkey рівнем процесу браузера.
Покращити виявлення аномального використання ключів: у синхронізованих системах лічильник підписів зазвичай статичний, тому сервіси майже не бачать ознак копіювання облікових даних.

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

Спільна передумова всіх трьох сценаріїв — заражений комп’ютер з 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Ключі допускуменеджер паролівПароліПоділитисяFacebookThreadsКопіювати посиланняДрукПопередня статтяЯк дізнатися, що вашу мережу Wi-Fi зламали: ознаки, фальшиві точки доступу та план дійНаступна статтяЯк заблокувати окреме відео чи цілий канал на YouTube для дитини