Перенесення паролів і passkeys між менеджерами: як розвиваються специфікації FIDO Credential Exchange

FIDO Alliance розробляє відкриті специфікації для перенесення паролів, passkeys та інших облікових даних між менеджерами. Credential Exchange Format 1.0 має статус Proposed Standard, а Credential Exchange Protocol залишається Working Draft. Це важливий крок проти прив’язки до одного сховища, але ще не універсальна кнопка експорту, яку однаково підтримують усі платформи.

Чому звичайного CSV недостатньо

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

Passkey містить криптографічні матеріали та прив’язку до relying party. Його не можна безпечно перетворити на рядок «сайт — логін — пароль». Потрібні стандартизовані структури, захищений канал, підтвердження користувача й правила, які дані дозволено переносити.

CXF описує формат даних

Credential Exchange Format визначає, як представляти різні типи облікових даних під час передачі між застосунками. Спільна схема дозволяє менеджерам однаково розуміти поля, версії, ідентифікатори та додаткові властивості.

Формат сам по собі не визначає повний процес. Навіть правильно сформований об’єкт небезпечно передавати через відкритий файл або неперевіреному застосунку. Саме тому CXF використовується разом із протоколом обміну.

CXP керує безпечним перенесенням

Credential Exchange Protocol описує взаємодію між застосунком-джерелом і застосунком-приймачем на одному або різних пристроях. Він має забезпечити узгодження, авторизацію, передачу та підтвердження результату без довготривалого відкритого архіву.

На липень 2026 року FIDO позначає CXP як Working Draft. Це означає, що деталі можуть змінюватися, а документ не слід описувати як остаточно ратифікований протокол. CXF 1.0 має вищий статус Proposed Standard, але впровадження все одно залежить від продуктів.

Перенесення passkey не змінює сайт

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

Сервіс може застосовувати власні політики для синхронізованих і апаратно прив’язаних credentials. Не кожен ключ обов’язково придатний для експорту. Наприклад, корпоративна політика може вимагати фізичний security key або керований автентифікатор.

Біометрія не подорожує разом із ключем

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

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

Найнебезпечніший момент — авторизація експорту

Якщо шкідлива програма може тихо експортувати всі credentials, стандарт лише спростить крадіжку. Тому джерело повинно чітко показувати користувачеві, що саме переноситься, куди, і вимагати сильне підтвердження. Масовий обмін може потребувати повторної автентифікації або затримки.

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

Після імпорту виникає питання копій

«Перенести» може означати копіювати або перемістити. Якщо credential залишається в старому менеджері, користувач має дві активні копії з різними моделями захисту. Якщо джерело автоматично видаляє дані до підтвердження, помилка передачі може заблокувати доступ.

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

Сервісам потрібна власна сторінка керування passkeys

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

Процес відновлення не має повертати фішинговий пароль як слабкий обхід. Сервіс повинен оцінити резервні методи, повідомлення про зміни й затримку ризикових операцій. Розгортання passkeys та повне усунення паролів — різні етапи.

Що перевірити користувачеві

• Чи підтримують обидва менеджери стандартний захищений обмін.
• Які типи credentials переносяться, а які залишаються.
• Чи створюється відкритий файл і де він зберігається.
• Як підтверджується особа перед масовим експортом.
• Чи працюють ключі на сайтах після імпорту.
• Який резервний спосіб доступу залишився.
• Як видалити старі копії після перевірки.

Що перевірити розробнику менеджера

Потрібні точна підтримка версії CXF/CXP, захист локального сховища, контроль життєвого циклу сеансу, аудит без запису секретів і поведінка при частковій помилці. Інтерфейс не повинен маскувати копіювання під синхронізацію або обіцяти перенесення ключів, які політика не дозволяє експортувати.

Сумісність варто перевіряти не лише на власних тестових даних. Паролі можуть містити нетипові символи, passkeys — різні алгоритми й метадані, а великі сховища — дублікати та записи без повного набору полів. Імпорт повинен або коректно прийняти запис, або пояснити відмову без тихої втрати.

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

Стаття TechPulse про вибір менеджера паролів допомагає оцінити сховище й відновлення. Матеріал про надійні паролі залишається актуальним для сервісів, де passkeys ще не доступні.

Credential Exchange може зробити ринок менеджерів конкурентнішим і дати користувачеві реальний вихід із закритої екосистеми. Але до широкої сумісності потрібно уважно читати статус специфікацій і перевіряти фактичну реалізацію кожного продукту.

Першоджерела: огляд FIDO Credential Exchange, статуси CXF і CXP та звіт FIDO про використання passkeys у 2026 році.