Автентифікація без паролів — чи це можливо і як: Google про свої нові проєкти

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

Як прийти до цього світу без паролів і які проєкти для цього розробляє Google, на конференції Google I/O 2022 розповів Еджі Катамура, Developer Advocate у Google. Highload публікує головне із цього матеріалу.

WebAuthn — автентифікація з реальним ключем

Web Authentication, або WebAuthn, — це вебстандарт, який дозволяє користувачам автентифікуватися через FIDO-сумісний пристрій, або автентифікатор. 

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

Як працює WebAuthn

У WebAuthn є три учасники:

1. Фронтенд сайту.
2. Вебсервер.
3. Автентифікатор.

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

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

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

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

Коли вебсайт викликає navigator.credentials.get, користувачеві знову пропонують натиснути на ключ. Коли він це робить, автентифікатор підписує виклик і повертає підпис. Нарешті сервер перевіряє підпис з допомогою відкритого ключа. Користувач успішно пройшов автентифікацію.

Альтернатива ключам

Ключі безпеки — чудовий вибір для облікових записів з високим рівнем ризику або в корпоративних умовах. Для звичайних користувачів є варіант простіше — використовувати Platform Authenticators, які вже вбудовані в смартфони та комп’ютери. Тобто датчики відбитків пальців і камери з функцією розпізнавання облич.

Щоб використовувати Platform Authenticator з WebAuthn, потрібно прописати це в коді (authenticatorAttachment: ‘platform’, userVerification: ‘required’). В іншому схема роботи буде такою самою.

Під час роботи з Platform Authenticators потрібно враховувати дві особливості:

1. У поточній реалізації FIDO для автентифікації користувача потрібен список ідентифікаторів облікових даних. Тобто потрібно попросити користувача надати його ім’я перед автентифікацією.
2. Оскільки Platform Authenticators вбудовані у пристрій, їх можна використовувати лише на одному пристрої.

Ось які розв’язання цих проблем пропонує Google:

#1 Розв’язання проблеми з ім’ям користувача

Використовувати облікові дані, що виявляються (Discoverable Credentials). У такому випадку користувачі вибирають обліковий запис, який надається операційною системою пристрою, і проходять локальну автентифікацію для входу в систему, минаючи введення імені користувача.

У майбутньому ви також зможете створити швидку форму підпису, у якій буде всього одна кнопка WebAuthn. Ця функція вже підтримується в Chrome та інших браузерах, а наприкінці цього року з’явиться і в Android.

Щоб використати облікові дані, що виявляються, передайте порожній об’єкт allowCredentials при автентифікації.

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

#2 Розв’язання проблеми з одним пристроєм

Для цього є всього лиш одне слово — passkeys. Це аналог паролів, але passkeys є обліковими даними FIDO. У Chrome вони синхронізуються на всіх пристроях Android-користувача.

Наприклад, якщо користувач створює ключ доступу на вебсайті на одному пристрої Android, цей ключ доступний і на іншому пристрої Android за умови, що користувач зайшов через той самий акаунт Google.

Від веброзробників не потрібні додаткові дії для активації цієї функції на WebAuthn.

Оскільки passkeys засновані на стандарті FIDO, інші платформи (наприклад, Apple) уже розробляють аналогічні функції. Якщо ж говорити про Windows, то, якщо користувач хоче увійти в систему з комп’ютера, він може це зробити. Для цього потрібно відсканувати QR-код, вибрати обліковий запис та пройти автентифікацію через телефон.

При цьому авторизація за QR-кодом потрібна лише один раз. У наступні входи користувач може просто вибирати ім’я телефону зі списку облікових даних, що виявляються.

Passkeys на Android буде доступний пізніше 2022 року.

Як захистити сайт, що працює тільки з паролями

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

Використання одноразового пароля

Найнадійніший варіант — використовувати автентифікатор FIDO. Альтернативний варіант — попросити користувача ввести одноразовий пароль (OTP) та надіслати його в SMS або email.

Для оптимізації роботи можна використовувати WebOTP API у Chrome та автозаповнення одноразового коду у Safari. У цьому випадку потрібно спеціально форматувати SMS, щоб OTP заповнювався автоматично.

Identity federation

Ще одним надійним варіантом автентифікації є identity federation. Він складається зі стандартних протоколів, таких як OpenID Connect, OAuth або SAML. При використанні identity federation сторона (Relying Party, RP) може делегувати свій механізм автентифікації для входу користувачів до системи постачальника ідентичностей (Identity Provider, IdP)

Наприклад, багато хто з вас напевно реєструвався на різних вебсайтах через обліковий запис Google. Саме так і працює identity federation.

Проблема цього способу полягає в тому, що IdP можуть дізнатися, які RP відвідує користувач. Тому Google працює над новим API для браузера з функцією identity federation — Federated Credential Management API (FedCM).

Ось як він працюватиме.

Припустімо, ваш сайт — це RP. Як тільки користувач заходить на сайт, якщо він уже підписаний в IdP, з’являється діалогове віконце. Натиснувши кнопку «Продовжити як», користувач створює федеративний обліковий запис та входить на сайт під своєю ідентифікацією, наданою IdP.

Оскільки браузер є посередником у спілкуванні між RP та IdP, стан входу користувача в систему й інформація про його обліковий запис IdP не повідомляються RP доти, доки користувач не погодиться увійти до системи. Аналогічно те, з якого RP користувач намагається увійти в систему, теж не повідомляється IdP доти, доки користувач не погодиться увійти.

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