Google Password Manager: passkey-атаки | CyberCalm

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

ByНаталя ЗарудняГоловний редакторГоловний редактор та засновниця CyberCalm. Понад 10 років у сфері кібербезпеки та технологічної журналістики. Пишу про захист інформації, мобільну безпеку, штучний інтелект та соціальні мережі.Follow: 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 (Trusted Platform Module). Кожен із описаних сценаріїв атаки починається з того, що на комп’ютері вже функціонує шкідливий програмний код, який має права звичайного користувача, без адміністраторських повноважень.

Жоден із цих сценаріїв не передбачає зламу криптографії 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: платформа вимагала підтвердження користувача, але не перевіряла сам прапорець 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 як такої.

Рекомендації для розробників та сервісів

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

Актуальність для українських користувачів

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

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

Можливі дії вже зараз

  • Регулярно оновлюйте операційну систему та браузер Chrome, не відкладаючи перезапуск браузера після встановлення оновлень.
  • Уникайте запуску виконуваних файлів з отриманих електронною поштою або через месенджери архівів, навіть якщо відправник знайомий.
  • Для найбільш важливих облікових записів застосовуйте апаратний ключ безпеки FIDO2 замість синхронізованого passkey.
  • Звертайте увагу на несподівані запити PIN-коду відновлення Google Password Manager у Chrome під час звичайного входу. Такі запити є нормою лише при налаштуванні нового пристрою, а не при щоденній автентифікації.
  • Періодично переглядайте список пристроїв та ключів доступу в налаштуваннях безпеки облікового запису 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Копіювати посиланняДрукЩо думаєте?В захваті0Сумно0Смішно0Палає0Овва!0Попередня стаття

Як дізнатися, що вашу мережу Wi-Fi зламали: ознаки, фальшиві точки доступу та план дійНаступна стаття

Як заблокувати окреме відео чи цілий канал на YouTube для дитини

В тренді

ШІ визначає місце зйомки фото у 9 випадках із 10 — і шахраї вже будують на цьому фішинг

17.08.2026

Комбінації клавіш у Windows 11: повний довідник

18.08.2026

Російські хакери зламують акаунти через OAuth і привʼязку пристроїв у WhatsApp

21.08.2026

Як змінити обліковий запис Google за замовчуванням на Android

16.08.2026

Як вимкнути геолокацію на iPhone: повний контроль доступу застосунків

17.08.2026

Новини

Серпневий Patch Tuesday: Microsoft закрила 421 вразливість, зокрема 0-day для атак Lazarus

12.08.2026

Огляди

Браузери на Chromium замість Chrome: що ви втрачаєте разом із Google

11.08.2026

Огляди

Альтернативи Chrome у 2026 році: браузери для тих, хто дбає про приватність

10.08.2026

Новини

Google назвала дату вимкнення Assistant

06.08.2026

Джерело

No votes yet.
Please wait...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *