FIDO U2F — Універсальна Двофакторна Аутентифікація. Введення

Ні для кого не секрет, що сьогодні існує велика проблема з безпекою в інтернеті. Користувачі використовують легкі паролі і переиспользуют їх на інших ресурсах. Парольні менеджери все ще в новинку для звичайного користувача, і вашу бабусю ви навряд чи змусите використовувати випадкові одноразові паролі з високою ентропією. Життя тлін і біль...
На світанку веб2.0 ми стали розуміти, що паролів недостатньо і винайшли двофакторну аутентифікацію або 2FA.
Що з себе представляють 2FA рішення сьогодні?
  • SMS — одноразові паролі надіслані за допомогою SMS.
  • OTP(TOTP/HOTP) — одноразові паролі, згенеровані на основі майстер ключів. Приклади: Google Authenticator, Yubikey, банківські OTP токени.
  • Криптографічні Токени — апаратні засоби для багатофакторної аутентифікації користувачів. Приклади: RSA SecureID, Рутокен.
При великому виборі рішень, у користувачів до цих пір заводять акаунти. Так чому існуючі технології не вирішили проблему?

Причин багато:
  • Фішинг — практично всі перераховані рішення вразливі до MITM (людина посередині) атакам, і відповідно фішингу. Що зупинить користувача, який вже ввів свій логін і пароль, від введення одноразового паролю?
  • Безпека — в даному випадку я буду говорити саме про SMS. SMS на даний момент найпопулярніше рішення 2FA на ринку. Історії про перевипуску сім карти траплялися не тільки в Росії, але і в США ЮАР Великобритании та інших країнах. Майже всі провайдери надають можливість відновлення сім-карт і методи соціальної інженерії ще ніхто не відміняв.
  • Вартість — якщо ви швейцарський банк, і ваш клієнт зберігає семизначні суми іноземної валюти, то RSA токени це мізерна ціна для забезпечення безпеки облікових записів ваших клієнтів. А якщо ви Twitter або Facebook, то видавати недешеві токени кожному користувачеві просто неможливо. SMS теж коштує грошей, і якщо ви тримаєте аматорський аніме форум про дискусіях про те, як пропатчити KDE під FreeBSD, то ви навряд чи зможете дозволити собі SMS.
  • Сумісність — ніхто не любить возитися з драйверами, і це одна з причин того, що RSA і Рутокен все ще не завоювали світ.
  • Зручність використання — вводити одноразові паролі це морока. Разблокируй екран, відкрий повідомлення, прочитай код, помилися, спали телефон і комп'ютер — це стандартний алгоритм взаємодії користувача і двофакторної аутентифікації.
Цей список можна ще довго продовжувати, але я думаю що думка донесена. Сьогоднішні рішення не в змозі надійно захистити користувача, складні в застосуванні, дороги і не універсальні.
FIDO U2F — Универсализируем другий фактор
У 2013 році в Кремнієвій Долині був організований FIDO (Fast IDentity Online) альянс для того, щоб адресувати проблеми легкої і безпечної аутентифікації в інтернеті. На даний момент FIDO має більш трьохсот асоціативних членів і тридцять членів правління. У список членів правління входять такі компанії як Google, Yubico, Microsoft, Visa, Mastercard, American Express, Paypal і інші.
Основні цілі, які FIDO ставить перед собою, це прості у використанні, безпечні, приватні і стандартизовані рішення.
На даний момент FIDO представили два стандарти: U2F (Universal Second Factor) — універсальний другий фактор, UAF (Universal Authentication Framework) — універсальний аутентифікаційні фреймворк для біометричної аутентифікації. Сьогодні ми поговоримо про U2F. Якщо тема цікава, то в майбутньому я можу написати статтю по UAF.
U2F це відкритий, бездрайверный протокол для двофакторної аутентифікації, заснований на виклик-відповідь аутентифікації за допомогою електронного цифрового підпису.
Як це працює?
У U2F протоколу три рівня абстракції: Користувач, Браузер(тех. Клієнт) і сам Протокол.
Користувач

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

Алгоритм взаємодії з U2F на стороні браузера такий:
  • Користувач проходить верифікацію логіна і пароля
  • Залежна сторона, Google наприклад, через U2F JS API запитує підпис виклику(challenge)
  • Браузер пересилає запит пристрою
Якщо користувач підтвердив, наприклад за допомогою натискання кнопки або іншим чином, своє бажання провести двофакторну аутентифікацію, то пристрій повертає підпис виклику
  • Браузер передає підпис залежною стороні
  • Залежна сторона веріфіцірует підпис
Протокол — або п'ять з половиною кроків до безпечної двофакторної аутентифікації
Крок перший — Виклик-Відповідь

Для початку ми виробляємо простий виклик-відповідь. Сервер посилає нам випадковий виклик. Наш пристрій підписує виклик і повертає підпис сервера, після чого сервер звіряє підпис.
Крок другий — Захист від фішингу
Підписуємо оригінальний URL і Channel IDПідписуємо оригінальний URL і Channel ID
Сам по собі виклик-відповідь не вирішує проблеми фішингу, так як якщо ви залогинились на rnail.ru замість mail.ru, то ваша підпис все ще може бути використана для входу у ваш аккаунт. Для захисту від цього браузер до викликом додає URL, з якого був зроблений запит на підпис, ID каналу TLS, після чого залежна сторона звіряє ці дані.
Крок третій — Приватність або реєстраційно-залежна пара ключів
Генеруємо реєстраційно-залежну паруГенеруємо реєстраційно-залежну пару
На даний момент наш пристрій підписує всі однією парою ключів. Це створює проблему для приватності, у зв'язку з тим, що публічний ключ буде скрізь однаковий. Для прикладу скажемо якби ви були зареєстровані на сумнозвісному AshleyMadison.com, то атакуючий міг би зв'язати злитий публічний ключ і інші ваші акаунти і потенційно заподіяти фізичну і моральну шкоду.
Щоб зберегти приватність при реєстрації, залежна сторона передає ID додатка (AppID) і насіння (випадкове число). На основі цих даних пристрій генерує унікальну реєстраційно-залежну пару ключів. Як пристрій генерує пару не описано в протоколі, а повністю віддано на розсуд виробника пристрою. Наприклад, кожен Yubikey має свій майстер ключ, який в зв'язці з HMAC ДПРЧ (Генератор псевдовипадкових чисел) генерує нову пару.
[https://developers.yubico.com/U2F/Protocol_details/Key_generation.html](https://developers.yubico.com/U2F/Protocol_details/Key_generation.html)https://developers.yubico.com/U2F/Protocol_details/Key_generation.html
За рахунок того, що пара ключів унікальна для кожної реєстрації, стає можливим використовувати спільно одне U2F пристрій для безлічі записів.
Крок четвертий — Захист від клонування

Так як U2F це тільки протокол, то він може мати різні імплементації, в залозі і ПО. Деякі імплементації можуть бути стійкими до клонування. Для захисту від цього U2F пристрій має вбудований лічильник. Кожен підпис і реєстрація збільшує стан лічильника на одиницю. Стан лічильника підписується і повертається залежною стороні. Якщо U2F пристрій було склонировано, то стан лічильника клонованого пристрої швидше за все буде менше ніж стан лічильника оригінального пристрою, що викличе помилку під час верифікації.
Крок п'ятий— Атестація Ключа

Різні імплементації протоколу можуть бути небезпечні. Щоб уникнути цього, кожне U2F пристрій має вбудований партійний сертифікат, який встановлюється приблизно на кожні сто тисяч пристроїв. Кожен підпис і реєстрація додатково підписується сертифікатом, публічний ключ якого знаходиться в публічній директорії.
Навіщо це треба? Наприклад, якщо ви — форум про кошенят, то ви можливо не сильно хвилюєтеся про те, наскільки безпечні U2F пристрої ваших користувачів, а якщо ви банк, то можливо ви дозволите тільки пристрої, виконані в залізі, і тільки якщо вони сертифіковані FIDO альянсом.
Крок шість з половиною — Захист від перебору

В ситуації, коли користувач знаходиться далеко від свого пристрою, шкідливе програмне забезпечення може спробувати атакувати пристрій методом повного перебору або іншими видами атак. Для захисту від цього U2F стандарт вимагає, щоб всі імплементації, в залозі і, активувалися користувачем. Користувач зобов'язаний підтвердити своє рішення на двофакторну аутентифікацію. Цією дією може бути просте натискання на кнопку, введення пін-коду, зняття відбитка пальця або інше.
Сервіси з численними точками входу
Візьмемо для прикладу Gmail.

Gmail можна увійти як з веб інтерфейсу, так і з мобільного. Як можна провести авторизацію користувача з android-додатки, якщо AppID нашого додатка і AppID сервісу будуть відрізнятися?
Для цього є фасети (facets).
Фасети — це JSON файл зі списком всіх ID, яким дозволяється проводити аутентифікацію для обраного сервісу. Для прикладу, ось фасети Google:
{
"trustedFacets": [{
"version": { "major": 1, "minor" : 0 },
"ids": [
"https://accounts.google.com",
"https://myaccount.google.com",
"https://security.google.com",
"android:apk-key-hash:FD18FA800DD00C0D9D7724328B6...",
"android:apk-key-hash:Rj6gA3QDA2ddyQyi21JXly6gw9...",
"ios:bundle-id:com.google.SecurityKey.dogfood"
]
}]
}

Фасети повинні бути в тому ж доменному просторі, що і AppID. Наприклад, якщо наше AppID це https://example.com/facets.json, https://**security**.example**.com пройде перевірку, а https://security.example.net **ні.
Для мобільних додатків фасети мають URI схему виду «OS:TYPE:ID». Для андроїда обчислюється SHA-1 сертифікату підпису апк. Для IOS це bundle ID.
Фасети зобов'язані лунати по HTTPS!
Специфікації

На даний момент готові специфікації для USB, NFC і Bluetooth LE.
Підтримка браузерами

Chrome підтримує U2F з коробки з початку 2015. U2F підтримка Firefox в даний момент в активній розробці. Microsoft анонсувала підтримку U2F як для Windows 10 так і для Edge як частина FIDO2.0 стека, і вона вже доступна в Insider Build.
Хто використовує?

Google, Github, Wordpress, Dropbox, Evernote. Уряд Великобританії нещодавно ввів підтримку U2F для своїх державних сайтів, що доставляє чимало.
Що потрібно врахувати при переході на U2F?
  • HTTPS ОБОВ'ЯЗКОВИЙ —мало того, що якщо ви не надаєте HTTPS своїм користувачам, то вас не турбує їх безпеку, і U2F вам буде мало цікавий. Firefox, Chrome, і Edge вимагають HTTPS з'єднання для використання U2F API.
  • Спробуйте TLS SessionID.
  • U2F це другий чинник. Не будьте як банки. Не використовуйте 2FA як основний фактор.
Підводимо підсумки
U2F це добре продумана, сильна, відкрита і стандартизована технологія. Вона була успішно протестована Google на своїх співробітників, які використовують U2F на даний момент в якості основного методу двофакторної аутентифікації.
U2F лише протокол, що тягне за собою створення величезного ринку рішень на основі його. Від крипто-ключів з безпечним елементом, JavaCard імплементацій, до мобільних додатків і біометричний-захищених U2F пристроїв, U2F дає волю вашої фантазії у тому, де його можна застосувати.
Примітки
Якщо ви хотіли б більше дізнатися про U2F і його впровадженні, а так само про інших рішеннях FIDO альянсу, пишіть в коментарях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.