Аутентификация fido что это
Что такое двухфакторная аутентификация и протокол FIDO U2F
Авторизуйтесь
Что такое двухфакторная аутентификация и протокол FIDO U2F
Миллионы логинов и паролей к почтовым и различным социальным сервисам появляются в открытом доступе чуть ли не каждый месяц. Это лучше любого эксперта по информационной безопасности свидетельствует нам о том, что пароль, даже сложный, уже не является актуальным средством защиты.
Меняются предпочтения пользователей в выборе того или иного сервиса. Если раньше выбор падал на наиболее удобный вариант, то теперь — на максимально защищённый.
Для обеспечения безопасности изобрели мультифакторную аутентификацию (MFA) и ее упрощенный вариант – двухфакторную (2FA): первый рубеж защиты – логин и пароль, т.е. то, что знает и помнит пользователь, а второй – это то, что есть только у этого пользователя: SMS, Email, one-time password (OTP/TOTP/HOTP) приложения, криптографические токены, биометрические данные. Наиболее дешёвые и удобные способы — приложение и SMS. Вводим логин и пароль на сайте, после чего получаем на мобильный телефон SMS с кодом. Вводим код, и у нас есть доступ к данным.
Мир 2FA сегодня
С момента появления 2FA прошло уже достаточно много времени, большинство крупных интернет-сервисов широко ее используют. 2FA «шагнула» в финтех: невозможно уже себе представить онлайн платежи без подтверждений и авторизации, например, через SMS.
И, как ни странно, при таком широком распространении 2FA у пользователей до сих пор крадут и компрометируют учетные записи. Попробуем разобраться в недостатках методов 2FA и их уязвимостях.
Сегодняшние 2FA-решения не в состоянии надежно защитить пользователя, зачастую сложны в применении, дороги и не универсальны.
FIDO U2F
В 2007 году PayPal попыталась внедрить 2FA с отправкой OTP через SMS. Несмотря на то, что на тот момент этот способ был прогрессивным и достаточно безопасным, темпы его внедрения были катастрофично низки. Большинство пользователей просто проигнорировало возможность увеличить безопасность своих данных.
Исследуя возможности по внедрению биометрических технологий, PayPal совместно с Validity Sensors, первыми озвучили мысль о том, что пора создать отраслевой стандарт, который бы поддерживал все аппаратные средства аутентификации. В 2013 году был основан FIDO (Fast IDentity Online) — альянс, ставящий себе задачей именно создание такого стандарта. Множество крупных компаний, таких как Google, ARM, Bank of America, Master Card, Visa, Microsoft, Samsung, LG, Dell и RSA стали его членами.
На данный момент, основные цели, которые FIDO ставит перед собой — это простые в использовании, безопасные, приватные и стандартизированные решения.
Результатом деятельности FIDO пока стали два стандарта: U2F (Universal Second Factor) и UAF (Universal Authentication Framework для биометрической аутентификации).
Что из себя представляет U2F?
U2F — это открытый, бездрайверный протокол, изначально разрабатываемый компаниями Google и Yubico и использующий для двухфакторной аутентификации специальные USB, NFC, Bluetooth LE устройства или SIM-карту (спецификации еще в разработке), которые хранят ключи и самостоятельно выполняют криптографические операции.
На данный момент поддержка U2F реализована в браузерах Chrome и Edge, а также в OS Windows 10.
Протокол основан на challenge-response аутентификации с помощью электронной цифровой подписи.
Со стороны пользователя
С точки зрения пользователя работа с протоколом достаточно тривиальна. Пользователь вводит логин и пароль, вставляет в компьютер USB (или использует Bluetooth или NFC) U2F устройство (нажимает на нем кнопку, вводит пин-код, проходит биометрическую проверку или не делает ничего) и успешно проходит аутентификацию.
Углубление в протокол U2F
Взаимодействие с U2F-клиентом (например, браузером или Windows 10) проходит следующим образом:
Рассмотрим работу протокола подробнее.
Пользователь вводит логин и пароль, сервер проверяет учетные данные и, если они верны, генерирует случайный challenge и отправляет его клиентскому ПО, которое, в свою очередь, передает его U2F-устройству. U2F-устройство ожидает участия пользователя для подтверждения дальнейших операций (как говорилось выше, например, нажатия кнопки на устройстве) и затем, возвращает клиентскому ПО подписанный challenge, который передается дальше на сервер для сверки подписи.
Для защиты от фишинга клиентское ПО добавляет к challenge origin URL, TLS channel ID перед отправкой U2F устройству, а сервер, после получения подписи, сверяет полученные данные.
Чтобы не подписывать все подряд одной парой ключей (что, естественно приведет от компрометации одного аккаунта какого-либо сервиса до компрометации сразу всех аккаунтов, использующих данное U2F-устройство), при регистрации сервер передает вместе с challenge параметры application ID и random seed, на основе которых U2F-устройство и генерирует уникальную пару Registering Dependent Keys. Причем ее способ генерации не описан в протоколе и полностью отдан на усмотрение изготовителя устройства.
За счет того, что пара ключей уникальна для каждой регистрации, становится возможным использовать совместно одно U2F-устройство для множества аккаунтов.
Для того, чтобы защитить U2F-устройство от клонирования, стандарт предусматривает в нем встроенный счетчик. Каждая подпись и регистрация увеличивает состояние счетчика на единицу. Состояние счетчика подписывается и возвращается зависимой стороне вместе с response. Если U2F-устройство будет клонировано, то состояние счетчика клонированного устройства будет меньше, чем состояние счетчика оригинального устройства, что вызовет ошибку во время верификации.
Для того, чтобы избежать небезопасных реализаций, каждое U2F-устройство имеет встроенный сертификат, гарантирующий клиентскому ПО и серверу, что оно является аппаратным и сертифицировано альянсом FIDO.
В ситуации, когда пользователь находится вдали от своего устройства, вредоносное программное обеспечение может попытаться атаковать устройство. Для защиты от этого U2F-стандарт требует, чтобы все операции подписания challenge активировались пользователем. Т.е. пользователь обязан подтвердить свое решение на двухфакторную аутентификацию. Как уже говорилось выше, это может быть простое нажатие на кнопку, ввод пин-кода, снятие отпечатка пальца или что-то другое.
Заключение
U2F — это хорошо продуманная, сильная, открытая и стандартизированная технология. Из крупных внедрений U2F можно отметить сервисы Google, Github, Dropbox, а также государственные сайты Великобритании.
Важно помнить, что U2F, как и любая другая технология двухфакторной аутентификации, должна использоваться именно как второй фактор.
Об авторе
Максим Советкин окончил механико-математический факультет Белорусского государственного университета, работает в Itransition уже более семи лет. Сегодня он – ведущий системный инженер, отвечает за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.
Как использовать смартфон Android в качестве электронного ключа безопасности для аккаунта Google
Двухфакторная аутентификация (или двухшаговая аутентификация) – это функция безопасности, которую нужно использовать в аккаунтах всех сервисов, которые мы хотим защитить.
Аккаунты Google являются очень привлекательной мишенью для хакеров, которые хотят завладеть пользовательскими данными. Технологический гигант разработал несколько методов для защиты ваших данных, включая несколько способов для предотвращения попыток взлома аккаунта.
Как известно, лучшим и менее подверженным компрометации способом для защиты аккаунта является использование физического ключа безопасности.
Однако, приобретение и постоянное использование физического ключа создает дополнительные неудобства для пользователей. Поэтому Google применила альтернативный подход и теперь позволяет превратить свои смартфоны в электронные ключи безопасности.
Смартфон Android в роли электронного ключа безопасности
Другими словами, смартфон Android или iPhone выступает в роли ключа безопасности и позволяет пользователям разрешать или отклонять попытки авторизации в свои аккаунты.
Google рекомендует использовать данную опцию в рамках программы «Дополнительная защита», которая будет полезна «журналистам, правозащитникам, бизнесменам, политикам и тем пользователям, которые чаще других подвергаются целенаправленным атакам».
Тем не менее, данную возможность может использовать любой владелец персонального аккаунта Google или рабочего аккаунта Google Cloud.
Чтобы использовать смартфон Android в качестве электронного ключа безопасности, мобильное устройство и ПК должны отвечать следующим требованиям:
Конечно, существуют и другие способы для защиты аккаунтов Google, например двухфакторная аутентификация с помощью кодов проверки, которые отправляются на мобильный телефон. Однако, в случае компрометации мобильного устройства хакеры могут перехватить проверочный код.
Ключи безопасности используют шифрование с открытым ключом для проверки вашей личности и URL-адрес страницы входа, чтобы злоумышленник не получил доступ к вашему аккаунту, даже если ему известны логин и пароль. В отличие от методов двухфакторной аутентификации (2FA), которые пытаются выполнить дополнительную проверку авторизации, ключи безопасности соответствуют стандартам FIDO для обеспечения надежной защиты против автоматизированных ботов, массовых фишинг-атак и целенаправленных мошеннических атак.
Как настроить электронный ключ безопасности для Android смартфона
Смартфоны Android уже имеет встроенный ключ безопасности, поэтому нужно только настроить использование аккаунта Google со смартфоном для двухфакторной аутентификации.
Во-первых убедитесь, что ваш смартфон добавлен в аккаунт Google, который вы хотите защитить, и в нем включена двухэтапная аутентификация.
Затем на ПК или мобильном устройстве нужно войти в аккаунт Google. Выберите опцию «Добавить электронный ключ» на странице управления аккаунтом по следующему пути:
Затем вам нужно выбрать устройство, которые вы хотите использовать в качестве ключа безопасности. Вот почему смартфон должен быть привязан к аккаунту Google, в противном случае вы просто не увидите его в списке телефонов, которые можно настроить как электронный ключ.
После завершения настройки, вы получите следующее сообщение:
Готово! Электронный ключ добавлен
Электронные ключи устройства [имя устройства] добавлены в аккаунт.
Теперь для входа в аккаунт с помощью двухэтапной аутентификации вам понадобится пароль и устройство [имя устройства].
Убедитесь, что включены Bluetooth и определение местоположения
В следующий раз при попытке входа в аккаунт Google, вы должны будете подтвердить это действие на своем мобильном телефоне.
После подтверждения входа, вы получите доступ к своему аккаунту.
Руководствуясь данной инструкцией, всегда можете изменить данные параметры, удалять устройства и добавлять новые устройства в качестве электронных ключей. Не забывайте, что ваш компьютер должен иметь Bluetooth-модуль, иначе данные о попытке авторизации не будут отправлены на ваш смартфон. Кроме того, вы должны включить службы геолокации на своем смартфоне.
FIDO U2F — Универсальная Двухфакторная Аутентификация. Введение
Ни для кого не секрет, что сегодня существует большая проблема с безопасностью в интернете. Пользователи используют легкие пароли и переиспользуют их на других ресурсах. Парольные менеджеры все еще в новинку для обычного пользователя, и вашу бабушку вы вряд ли заставите использовать случайные одноразовые пароли с высокой энтропией. Жизнь тлен и боль…
На заре веб2.0 мы стали понимать, что паролей недостаточно и изобрели двухфакторную аутентификацию или 2FA.
Что из себя представляют 2FA решения сегодня?
SMS — одноразовые пароли отправленные с помощью SMS.
OTP(TOTP/HOTP) — одноразовые пароли, сгенерированные на основе мастер ключей. Примеры: Google Authenticator, Yubikey, банковские OTP токены.
При большом выборе решений, у пользователей до сих пор уводят аккаунты. Так почему существующие технологии не решили проблему?
Фишинг — практически все перечисленные решения уязвимы к 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
Сам по себе вызов-ответ не решает проблемы фишинга, так как если вы залогинились на rnail.ru вместо mail.ru, то ваша подпись все еще может быть использована для входа в ваш аккаунт. Для защиты от этого браузер к вызову добавляет URL, с которого был произведен запрос на подпись, и ID канала TLS, после чего зависимая сторона сверяет эти данные.
Шаг третий — Приватность или регистрационно-зависимая пара ключей
Генерируем регистрационно-зависимую пару
На данный момент наше устройство подписывает все одной парой ключей. Это создает проблему для приватности, в связи с тем что публичный ключ будет везде одинаковый. Для примера скажем если бы вы были зарегистрированы на печально известном AshleyMadison.com, то атакующий мог бы связать слитый публичный ключ и ваши другие аккаунты и потенциально причинить физический и моральный вред.
Чтобы сохранить приватность при регистрации, зависимая сторона передает ID приложения (AppID) и семя (случайное число). На основе этих данных устройство генерирует уникальную регистрационно-зависимую пару ключей. Как устройство генерирует пару не описано в протоколе, а полностью отдано на усмотрение изготовителя устройства. Например, каждый Yubikey имеет свой мастер ключ, который в связке с HMAC и ГПСЧ (Генератор псевдослучайных чисел) генерирует новую пару.
За счет того, что пара ключей уникальна для каждой регистрации, становится возможным использовать совместно одно U2F устройство для множества аккаунтов.
Шаг четвертый — Защита от клонирования
Так как U2F это только протокол, то он может иметь разные имплементации, в железе и ПО. Некоторые имплементации могут быть не устойчивыми к клонированию. Для защиты от этого U2F устройство имеет встроенный счетчик. Каждая подпись и регистрация увеличивает состояние счетчика на единицу. Состояние счетчика подписывается и возвращается зависимой стороне. Если U2F устройство было склонировано, то состояние счетчика клонированного устройства скорее всего будет меньше чем состояние счетчика оригинального устройства, что вызовет ошибку во время верификации.
Шаг пятый— Аттестация Ключа
Разные имплементации протокола могут быть быть небезопасны. Чтобы избежать этого, каждое U2F устройство имеет встроенный партийный сертификат, который устанавливается приблизительно на каждые сто тысяч устройств. Каждая подпись и регистрация дополнительно подписывается сертификатом, публичный ключ которого находится в публичной директории.
Зачем это надо? Например, если вы — форум о котятах, то вы возможно не сильно волнуетесь о том, насколько безопасны U2F устройства ваших пользователей, а если вы банк, то возможно вы разрешите только устройства, выполненные в железе, и только если они сертифицированы FIDO альянсом.
Шаг шесть с половиной — Защита от перебора
В ситуации, когда пользователь находится вдали от своего устройства, вредоносное программное обеспечение может попытаться атаковать устройство методом полного перебора или другими видами атак. Для защиты от этого U2F стандарт требует чтобы все имплементации, в железе и ПО, активировались пользователем. Пользователь обязан подтвердить свое решение на двухфакторную аутентификацию. Этим действием может быть простое нажатие на кнопку, ввод пин-кода, снятие отпечатка пальца или другое.
Сервисы с множественными точками входа
Возьмем для примера Gmail.
В Gmail можно войти как с веб интерфейса, так и с мобильного. Как можно произвести авторизацию пользователя с андроид приложения, если AppID нашего приложения и AppID сервиса будут различаться?
Для этого есть фасеты (facets).
Фасеты — это JSON файл со списком всех ID, которым разрешается производить аутентификацию для выбранного сервиса. Для примера, вот фасеты Google:
Фасеты должны быть в том же доменном пространстве что и AppID. Например, если наше AppID это https://example.com/facets.json, то https://**security**.example**.com пройдет проверку, а https://security.example.net **нет.
Для мобильных приложений фасеты имеют URI схему вида “OS:TYPE:ID”. Для андроида вычисляется SHA-1 сертификата подписи apk. Для 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 это хорошо продуманная, сильная, открытая и стандартизированная технология. Она была успешно протестирована Google на своих сотрудниках, кои используют U2F на данный момент в качестве основного метода двухфакторной аутентификации.
U2F всего лишь протокол, что влечет за собой создание огромного рынка решений на основе его. От крипто-ключей с безопасным элементом, JavaCard имплементаций, до мобильных приложений и биометрически-защищенных U2F устройств, U2F дает свободу вашей фантазии втом, где его можно применить.
Примечания
Если вы хотели бы больше узнать о U2F и его внедрении, а так же о других решениях FIDO альянса, пишите в комментариях.
Как работает FIDO
FIDO (Fast IDentity Online) Альянс был создан в июле 2012 года для решения проблемы поддержки устройств строгой аутентификации в сети Интернет, а также с целью упростить жизнь пользователям, вынужденным создавать и запоминать имена пользователей и пароли. FIDO Альянс планирует изменить текущую ситуацию с аутентификацией путем разработки спецификаций, определяющих набор механизмов, которые вытеснят зависимость от паролей и обеспечат безопасную аутентификацию пользователей интернет-услуг. Новый стандарт по безопасности устройств и плагинов для браузеров позволит любому веб-сайту или облачному приложению взаимодействовать с широким спектром существующих и перспективных устройств для обеспечения безопасной аутентификации пользователей.
Для обеспечения безопасной работы пользователей проект FIDO объединяет аппаратные средства, программное обеспечение и интернет-сервисы.
Если кто не знаком с FIDO, перевод раздела сайта «Как работает FIDO» ниже. А сейчас небольшие комментарии.
Нашей командой разрабатывалось решение по аппаратной аутентификации на web-ресурсах. Решение получилось вполне удачным, оно используется в системах документооборота и в механизмах лицензирования SaaS. Техническая часть проекта FIDO достаточно схожа с нашими разработками и выглядит вполне выполнимой. Однако, из описания на сайте FIDO становится ясно, что четкого понимания что и как делать у них пока нет. Да и сама концепция вызывает ряд вопросов.
FIDO альянсом предполагается следующий механизм распространения устройств аутентификации. На этапе производства устройства получают идентификационный номер и секрет. Эта информация помещается производителем в FIDO Repository. При регистрации нового пользователя сервис запрашивает идентификационный номер устройства и по этому номеру получает из FIDO Repository данные, необходимые для проверки пользователя при аутентификации. Эти данные кэшируются интернет-сервисом в Validation Cache для снижения нагрузки на FIDO Repository.
К сожалению, о используемых криптоалгоритмах и протоколах пока ничего не сказано. Однако по косвенным признакам (в тексте встречается термин OTP, а также по схеме с Репозиторием) можно предположить, что планируется использовать симметричные алгоритмы. Для меня такое решение выглядит несколько устаревшим. Безопасное распространение симметричных ключей, чем по видимому должен заниматься Репозиторий, выглядит сомнительным. По логике вещей каждое устройство при регистрации на новом интернет сервисе должно бы генерировать новый ключ самостоятельно. То есть, для каждого сервиса свой ключ и никаких глобальных идентификационных номеров. Кроме того, что бы не хранить на сервере какие-либо секретные ключи, думается, разумно использовать ассиметричные алгоритмы.
FIDO предполагает использование двух основных типов устройств для аутентификации. В их терминологии это Identification tokens и Authentication tokens. Первый вариант не требует аутентификации владельца. То есть пока устройство подключено, аутентификация происходит прозрачно для пользователя. Несомненно удобно. Однако, этим механизмом может воспользоваться кто угодно, имеющий доступ к устройству, например жена сможет читать переписку мужа. Думаю, отказываться от второго фактора все-таки нельзя.
Как ни печально, но использование глобального идентификатора еще и позволяет построить связь между разными учетными записями по номеру устройства, а это не всем понравится. В настоящее время и так есть серьезные проблемы с приватностью в сети интернет, а такой подход еще и усугубляет эту проблему. Думается, никаких глобальных идентификаторов быть не должно, никакой необходимости в них в общем нет.
В концепции ничего не сказано о механизмах взаимодействия в случае утраты аппаратного устройства. Удобное и безопасное решение этого вопроса весьма важно, так как может вызвать серьезное увеличение нагрузки на техподдержку.
Решение будет очевидно востребовано некоторой частью пользователей, ведущих какую-либо коммерческую деятельность в Интернет. Однако, для широкого, повсеместного применения строгой аутентификации нужно не только обеспечить безопасность, но и предложить решение которое будет удобными и модными. Популяризация разрабатываемого решения может стать одной из самых затратных частей этого проекта. В этом плане весьма обнадеживающе выглядит участие в этом альянсе не только разработчиков, но сервисов, таких как PayPal и Google.
Как работает FIDO
Пользователи будут иметь FIDO Аутентификатор или токен (любое аппаратное устройство аутентификации, поддерживающее механизмы FIDO — прим. переводчика), который они выбрали, или который им был выдан для пользования каким-либо сервисом. Например, такие устройства как биометрический сканер или USB носители с доступом по паролю. Пользователи могут выбрать такой тип FIDO Аутентификатора, который наилучшим образом отвечает их требованиям.
FIDO Аутентификаторы будет выпускаться в двух основных вариантах.
Identification tokens будут иметь уникальные ID, идентификаторы будут привязываться к аккаунту Интернет пользователя. После привязки к аккаунту, они будут доступны серверу в качестве идентификатора без необходимости каких-либо действий со стороны пользователя. Таким образом, будет обеспечиваться только один фактор аутентификации.
Authentication tokens может потребовать от пользователя выполнить какое-либо действий, чтобы доказать, что он законный владелец токена. Эти действия могут включать в себя ввод пароля, ввод PIN-кода или предоставление биометрических данных. Эти аутентификаторы обеспечат двухфакторную аутентификацию пользователя, используя принцип » что у вас есть» и «что вы знаете” или биометрический фактор „кто вы есть“.
Когда пользователь подключает свой FIDO Authenticator к аккаунту веб-ресурса, устанавливается связь между Аутентификатором, проверяющей стороной и Validation Cache. После создания связи, для проверки абонента используются одноразовые пароли (OTP). Так как пароль OTP используется только один раз, он не может быть использован для атак воспроизведения, если кто-то захватывает сеанс связи с вторжением в систему или слушает интернет-трафик.
Каждый аутентификатор будет иметь встроенный ID и начальное значение, которые позволят однозначно идентифицировать и проверить его подлинность. Криптографические операции будут происходить на борту Аутентификатора. Таким образом, даже если машина заражена вредоносным ПО, FIDO Аутентификатору еще можно доверять.
Браузеры пользователя будут иметь FIDO плагин. Плагин сможет распознавать доступные FIDO Аутентификаторы, которые подключены к системе пользователя. Включая в себя встроенные аутентификаторы и подключаемые по USB.
При подключении пользователя к веб-сайту браузер будет сообщать серверу о доступных FIDO Аутентификаторах в составе информации о браузере. Сайты, поддерживающие технологию FIDO смогут распознать наличие аутентификатора и отвечать соответствующим образом. На основании полученной информации проверяющая сторона (веб-сайт) инициирует механизм аутентификации.
FIDO плагин может распространяться через различные каналы, в том числе:
Browser Add-On — разработчики браузеров могут иметь плагин в качестве дополнения, которое пользователи могут скачать и подключить в свой браузер.
FIDO аутентификаторы — Если пользователь покупает FIDO аутентификатор, имеющий встроенный USB диск, плагин может располагаться на нем.
Вендоры– Вендоры могут распространять плагин с новыми машинами, а также включать плагин в состав обновлений программного обеспечения для существующих машин. Эти обновления позволят использовать FIDO аутентификацию на существующих машинах с подходящими аппаратными возможностями.
Device Specific Module
Специальный модуль устройства (DSM) будет взаимодействовать с плагином для браузера с одной стороны, и с аппаратным FIDO Токеном с другой. DSM преобразует команды плагина в команды, которые являются специфическими для каждого типа токена. Разделения программного обеспечения FIDO на плагин и DSM позволяет создать универсальный плагин для браузера, поддерживающий широкий спектр аппаратных устройств. Кроме того, это позволит поставщикам аппаратных решений сосредоточиться только на разработки той части ПО, которая необходимой для поддержки своих устройств, и не потребует реализовывать весь стек программного обеспечения.
Проверяющая сторона / Website
Как следует из названия, проверяющая сторона использует проверку токена для аутентификации.
Веб-сайт распознает наличия FIDO Токена, определяет привязан ли он к аккаунту и если нет, представляет пользователю возможность привязать новый токен к своему аккаунту.
Например, определив что токен привязан к аккаунту, web-сайт добавит на страницу входа сообщение „Войти с FIDO“. Если токен был определен как сканер отпечатков пальцев, сообщение может быть „проведите пальцем для входа с FIDO“.
В зависимости от политики сервера, предпочтений пользователя и истории аккаунта Identification tokens могут значительно упростить вход в систему. Веб-сайт может просто определить существующего пользователя и показать » Welcome back Debbie!» вместо окна входа, основываясь только на информации от FIDO токена. Конечно, пользователь сможет изменить параметры входа, определив для себя, насколько опасно это может быть для его учетной записи.
Validation Cache будет проверять зашифрованную информацию и одноразовые пароли получаемые от токенов, что бы быть уверенным в подлинности токена. Проверяющая сторона будет использовать Validation Cache, для проверки информации получаемой от каждого токена.
Стоит отметить, что наличие Validation Cache на сайте проверяющей стороны позволит получать ответ быстрее, избежать задержек с ответом или атак. Validation Cache будет регулярно получать обновления из FIDO Repository о новых устройствах произведенных поставщиками токенов.
FIDO Repository это центр обмена информацией о токенах. Производители токенов будут сообщать данные о каждом произведенном FIDO токене в Repository. Хранимая в Repository информация используется для проверки OTP генерируемого токеном. Repository будет регулярно обновлять Validation Cache на каждом сайте, который использует FIDO. Repository будут поддерживать большое количество сайтов и иметь механизмы репликации для обеспечения бесперебойного обслуживания. Веб-сайт сможет использовать более одного Repository.
FIDO Repository будет взаимодействовать с разработчиками, чтобы гарантировать актуальность и доступность базы токенов. Использование FIDO Repository позволит web-сайтам не иметь контактов с каждым поставщиком токенов. При подключении к FIDO Repository информация о всех существующих токенах будет доступна web-сервису.
Когда пользователь с новым токеном впервые переходит на сайт, который поддерживает технологию FIDO, сайт предположит пользователю привязать FIDO токен к своему аккаунту для повышения уровня безопасности в будущем. Информация о браузере пользователя сообщит сайту, что пользователь имеет FIDO токен, а также сообщит сайту тип токена. Если сайт поддерживает FIDO, он в фоновом режиме опросит плагин о токене. В зависимости от политики, сайт будет предлагать пользователю подключить FIDO токен к своему аккаунту.
Порядок действий может отличаться в зависимости от типа Аутентификатора пользователя, но все типы будут поддерживаться через один и тот же плагин.
Сканер отпечатков: пользователь проводит пальцем по датчику. Аутентификатор выполняет криптооперации, данные поступают в DSM, а затем в плагин браузера.
Защищенные паролем токены: пользователь вводит правильный пароль для токена.
Уникальный идентификатор устройства: Так как это не Authentication tokens, от пользователя требуется только нажать кнопку ОК для подключения идентификатора.
Когда пользователь соглашается подключить токен и аутентифицируется на нем (при необходимости), глобальный ID токена и ID пользователя шифруются и отправляются обратно на сайт. Сайт использует Validation Cache для проверки токена. После проверки токена, сайт привязывает уникальный ID токена к аккаунту пользователя для дальнейшего использования.
После того как пользователь привязал свой Токен к аккаунту он может использовать его вместо логина и пароля учетной записи. Ниже приведены три примера, но в перспективе FIDO будет поддерживать более широкий спектр FIDO токенов.
Считыватель отпечатков пальцев
Пользователь переходит на веб-сайте, его аккаунт привязан к токену со считывателем отпечатков пальцев.
Браузер сообщает сайту, что пользователь имеет FIDO токен со считывателем отпечатков для аутентификации, веб-сайт представляет пользователю вариант страницы аутентификации, поддерживающий FIDO. Веб-сайт может показать сообщение «Сканируйте палец для входа FIDO» Пользователь сканирует свои отпечатки. FIDO токен распознает пользователя. Биометрические данные пользователя никогда не покидает считыватель. Глобальный ID и аутентификационные данные шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора и идентификатора пользователя. Таким образом, обеспечивается двухфакторная аутентификацию, так как наличие токена со считывателем у пользователя является первым фактором и прохождение биометрической аутентификации является вторым фактором.
Если пользователь использовал токен со считывателем отпечатков, более чем с одной учетной записью, сайт будет запрашивать у пользователя имя аккаунта, к которому он хочет получить доступ.
Защищенные паролем токены
Пользователь переходит на веб-сайт, его аккаунт связан с защищенным паролем токеном. Это может быть USB токен или установленный на материнской плате модуль(TPM). Браузер сообщает сайту, что пользователь имеет FIDO токен с паролем, веб-сайт настраивает страницу аутентификации по технологии FIDO. Веб-сайт может представить пользователю сообщение «Нажмите здесь для безопасного входа с FIDO».
Когда пользователь нажимает на кнопку «FIDO Логин», плагин отображает локальное окно (не окно браузера) для ввода пароля токена. Этот пароль для локальной аутентификации в FIDO токене. Этот пароль не доступен через веб-браузер и должен быть передан только в токен.
FIDO токен аутентифицирует пользователя. Глобальный ID и аутентификационные данные шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора и идентификатор пользователя. Таким образом, обеспечивается двухфакторная аутентификация, так как наличие токена у пользователя является первым фактором, а знание пароля от токена является вторым фактором. Если пользователь использовал токен, более чем с одной учетной записью, сайт будет запрашивать у пользователя имя аккаунта, к которому он хочет получить доступ.
Пользователь переходит на веб-сайт, его аккаунт связан с Identification token. Это может быть встроенное аппаратное средство, дополнительные программные или аппаратные решения, которые не требуют знания PIN кода или пароля, так как они обеспечивают только идентификацию. Браузер сообщает сайту, что пользователь имеет Identification token, доступный для проверки подлинности. Веб-сайт будет запрашивать у плагина идентификационные данные. Обмен данными с сервером происходит в фоновом режиме, без взаимодействия с пользователем. Глобальный ID Identification token шифруются и отправляется обратно на сайт через DSM и плагин.
Сайт проверяет полученные данные через Validation Cache. Веб-сайт определяет пользователя на основании глобального уникального идентификатора. Если есть только одна учетная запись, связанная с идентификатором, то пользователь входит в свою учетную запись без пароля. Данный тип аутентификации является однофакторным, так как для аутентификации достаточно только владеть идентификатором.
Если политика сайта требует двухфакторную аутентификация, то от пользователя может потребоваться ввести свой пароль. В качестве второго фактора, без дополнительного взаимодействия с пользователем, проверяется наличие Identification token.
Новые типы Аутентификаторов
Одной из целей FIDO является расширение спектра устройств. Намерение состоит в том, чтобы все устройства безопасности, которые соответствуют интерфейсу FIDO плагина, должны быть доступны для всех веб-сайтов без изменения кода. Это позволит легко подключать к системе новые типы токенов.
Чтобы добавить новый тип аутентификации разработчик должен создать устройство, DSM и протестировать его с плагином. Затем разработчик должен передать в FIDO Repository данные, необходимые для проверки новых устройств. Repository будет гарантировать, что данные будут доступны всем Validation Cache проверяющих сторон.
Когда новый аутентификатор появляется на сайте в первый раз, сайт будет проверять аутентификатор с помощью Validation Cache. Веб-сайт может попросить пользователя выполнить какие-либо дополнительные действия для аутентификации пользователя, не зная подробностей этих действий, так как взаимодействие происходит через плагин и DSM. Когда пользователь выполнит необходимые действия, идентификационные данные будут подключены к учетной записи пользователя.