Не використовуйте ключі доступу для шифрування даних користувача

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

Автентифікація та шифрування – принципово різні роботи

Автентифікація дає відповідь на одне запитання: "Ви є тим, за кого себе видаєте?" Шифрування відповідає на зовсім інше питання: «Чи можуть ці дані залишатися нечитабельними для всіх, крім авторизованих сторін?» Ці дві проблеми мають спільні криптографічні примітиви, але інженерні вимоги різко відрізняються. Автентифікація має відбуватися один раз за сеанс, може допускати випадкові збої з витонченими резервними варіантами та не потребує щоразу створювати однаковий результат. Шифрування вимагає детермінованого, відтворюваного доступу до ключа протягом усього терміну служби даних — який може тривати роки або десятиліття.

Під час автентифікації за допомогою ключа ваш пристрій генерує криптографічний підпис, який підтверджує, що ви володієте закритим ключем, пов’язаним із вашим обліковим записом. Сервер перевіряє цей підпис і надає доступ. У жодному разі сервер або навіть ваша програма не отримують доступу до самого матеріалу закритого ключа. Це функція, а не обмеження. Вся модель безпеки ключів доступу залежить від того, що закритий ключ ніколи не залишає захищений анклав вашого пристрою. Але шифрування вимагає, щоб ви використовували ключ для перетворення даних, а потім використовували той самий ключ (або його аналог) для зворотного перетворення. Якщо ви не можете надійно отримати доступ до ключа, ви не зможете надійно розшифрувати його.

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

Чому ключі доступу не використовуються як ключі шифрування

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

Немає експорту ключа: особисті ключі, згенеровані під час реєстрації ключа доступу, зберігаються в захищених анклавах з апаратною підтримкою (TPM, Secure Enclave або еквівалент). Операційна система та API-інтерфейси браузера не надають механізмів для отримання необробленого ключового матеріалу. Ви можете попросити ключ щось підписати, але ви не можете прочитати сам ключ.

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

Доступність на пристрої: навіть із синхронізацією ключа доступу (iCloud Keychain, Google Password Manager) доступність залежить від участі в екосистемі. Користувач, який зареєструвався на iPhone, а потім перейшов на Android, може втратити доступ. Користувач, чий пристрій втрачено, вкрадено або скинуто до заводських налаштувань, стикається з тією ж проблемою.

Лише виклик-відповідь: API WebAuthn надає navigator.credentials.get(), який повертає підписане твердження, а не необроблений ключ. Ви отримуєте підпис під викликом, наданим сервером — корисний для підтвердження особи, марний для отримання ключа шифрування.

Немає гнучкості алгоритму: ключі доступу зазвичай використовують ECDSA з кривою P-256. Навіть якби ви могли отримати доступ до ключа, ECDSA — це алгоритм підпису

Frequently Asked Questions

Why can't passkeys be used to encrypt user data?

Passkeys are designed exclusively for authentication, not encryption. They rely on public-key cryptography to verify your identity during login, but the private key never leaves your device and isn't accessible to applications. Encryption requires stable, reproducible keys that can consistently decrypt data over time. Passkeys lack this capability by design, making them fundamentally unsuitable for protecting stored user information.

What happens if you try to encrypt data with passkeys anyway?

You risk building a brittle system where users get permanently locked out of their own data. Passkeys can be revoked, rotated, or replaced across devices without warning. If encrypted data is tied to a specific passkey that gets deleted or updated, there is no recovery path. This creates a catastrophic data-loss scenario that no amount of engineering workaround can reliably prevent.

What should developers use instead of passkeys for data encryption?

Developers should use purpose-built encryption solutions such as AES-256 with proper key management, envelope encryption, or established libraries like libsodium. Keep authentication and encryption as separate concerns. Use passkeys for what they excel at — passwordless login — and dedicated encryption keys managed through secure key derivation and storage systems for protecting sensitive user data.

How does Mewayz handle authentication and data security for businesses?

Mewayz provides a 207-module business OS starting at $19/mo that separates authentication from data protection using industry best practices. Rather than misusing passkeys, the platform at app.mewayz.com implements proper encryption layers alongside secure login flows, ensuring businesses can protect customer data reliably without risking the lockout scenarios that come from conflating authentication with encryption.

Related Posts

• Привілей - це погана граматика
• Show HN: Я створив базу знань маркетингу електронною поштою з 55 тисяч слів і навичок Клода Коду
• Японські вірші про смерть
• Вакансії в техніці знищуються таким чином, якого не бачили з 2008 року