что такое защитный код fido
Как использовать смартфон 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 на телефоне андроид: что это такое
06.06.2020 9,444 Просмотры
Мы живем в такое время, когда необходимо всегда заботиться о персональной безопасности. Но, а так как мы живем во время цифровых технологий, то прежде всего нужно позаботиться о безопасности наших данных в сети, на нашем смартфоне, онлайн-банкинге, электронной почте и так далее. И в сегодняшней статье речь пойдёт о защитном ключе Fido, а также двухфакторной аутентификации, как более безопасный способ защиты ваших данных.
Что же такое FIDO, двухфакторная аутентификация, как это работает на устройствах
Учитывая тот факт, насколько технологии прошли вперёд, что теперь практически у каждого есть возможность носить у себя в кармане смартфон, который сопоставим с мощными компьютерами и носителями важной информации. Сейчас можно любой смартфон сделать своим ключом для двухфакторной аутентификации. И если вы хотите максимально защититься, тогда используете её абсолютно для всех своих личных аккаунтов в сети.
Самыми популярными, а также самыми уязвимыми мишенями становятся сервисы Google, которые неоднократно подвергаются хакерским атакам. Но, чтобы защитить своих клиентов, разработчики сделали специальные способы защиты в виде ключей в несколько шагов. И если пользователь захочет войти в свои аккаунты, тогда он обязательно должны пройти все эти шаги.
Для кого доступны эти возможности
Как правило, все эти мери безопасности были придуманы для более уязвимых людей, а именно для:
Но, сейчас все эти функции доступны для каждого, поэтому никогда не будет лишним сделать свой аккаунт неприступной крепостью.
Как настроить
Если вы решились проделать все эти действия, тогда вам следует перейти в настройки своего телефона, к безопасности, аккаунт Google, а потом к двухфакторной аутентификации. Затем просто добавьте электронный ключ и дело в шляпе.
FIDO2 — Пароли must die
Думаю, все вы неоднократно слышали о том что «пароли мертвы», «пароли вымирают», «новая технология убьет пароли» и тому подобное.
Мы в FIDO Alliance как раз-таки пришли сообщить вам о том, что пароли все-таки вымрут… в аутентификации.
Прежде чем мы начнем разговор о массовом уничтожении многословных гадов, давайте вернемся к нашему самому популярному протоколу FIDO U2F о коем я писал ранее.
То есть сценарий аутентификации с U2F таков:
Регистрация:
— Пользователь регистрируется, используя логин и пароль
— Сервер хеширует пароль с использованием scrypt, argon2, bcrypt и сохраняет в БД
— Пользователь добавляет свое устройство, храня на сервере публичный ключ и id пары ключей на устройстве
Аутентификация:
— Пользователь вводит логин и пароль
— Сервер хеширует пароль и сравнивает с хешем в базе данных
— Сервер генерирует случайный «вызов» и отправляет клиенту вместе с ID
— Клиент передает вызов, id, token binding, и origin сессии U2F токену
— Аутентификатор все это подписывает приватным ключом и отправляет клиенту, а тот серверу
— Профит
На сегодняшний день мультифакторная аутентификация с использованием U2F является самым легким, фишинг устойчивым и безопасным методом аутентификации. Но даже у этого метода есть свои недостатки.
Пароли все еще можно украсть на всех стадиях аутентификации:
— Можно украсть с помощью кейлоггера;
— Можно украсть при проблемах с TLS(см Heartbleed);
— Можно украсть если сервер уязвим к инъекции кода, или при ошибках в коде(см Twitter)
— Можно украсть если пароли слабо хешированы или не были хешированы вовсе.
Пока есть пароль, его можно украсть
А что если убрать пароль вообще?
Собственно, так подумали мы в FIDO Alliance (мы не имеем ничего общего с гипертекстовым фидонетом, хотя потенциально можем быть там использованы) и сделали FIDO2
Для тех, кто о нас не слышал, FIDO Alliance — это консорциум, разрабатывающий открытые стандарты безопасной аутентификации. Выше на картинке вы можете видеть наших членов совета, которые собственно и разрабатывают стандарты.
FIDO2 — это наш последний проект, который мы разрабатывали более трех лет. Он состоит из двух частей:
— WebAuthn — JS API для менеджмента учетных записей на публичных ключах. Это W3C стандарт, так что будет обязателен для всех браузеров. Собственно Chrome, Firefox и Edge уже публично заявили о работе над его поддержкой.
— CTAP2 — Client-to-Authenticator 2 — это стандарт, описывающий CBOR протокол для общения с аутентификатором по USB, NFC и BLE.
Пользователь
Для пользователя это просто:
— Пользователь вводит имя
— Проходит верификацию
— Профит!
Протокол
FIDO2 — это член семейства вызов-ответ протоколов FIDO. В протоколе есть шесть основных механизмов безопасности:
1. Вызов-ответ
Первый механизм это вызов-ответ. Сервер генерирует случайный вызов и отправляет его клиенту. Клиент передает данный вызов аутентификатору, который подписывает вызов и возвращает его клиенту, а тот в свою очередь серверу. Сервер, зная вызов, подпись и публичный ключ, может подтвердить подпись и таким образом аутентифицировать клиента.
2. Фишинг-защита
Второй механизм это сессионно-зависимая транзакция. Когда клиент получает вызов от сервера, он добавляет к вызову информацию о сессии: origin (прим: example.com), token binding. Эта информация подписывается аутентификатором и возвращается серверу. Сервер декодирует ответ и смотрит или в источником был он сам, и если пользователь подвергся фишинг атаке то сервер сможет увидеть что источником был на пример attacker.com а не example.com и таким образом предотвратить атаку.
3. Защита от атаки повторного воспроизведения
Чтобы защитить от атаки повторного воспроизведения, в транзакции присутствует счетчик, который увеличивается на единицу при каждой операции. Если сервер получил ответ со счетчиком, значение которого меньше или равно последнему сохраненному значению, то сервер может точно сказать что это атака повторного воспроизведения.
4. Приватность
Четвертый механизм защиты это регистрационно-уникальные пары ключей. При каждой регистрации аутентификатор генерирует случайную пару ключей со случайным идентификатором. Таким образом даже если вы и ваш партнер будете использовать один аутентификатор для обоих аккаунтов, то сервер не сможет узнать этого.
При аутентификации идентификатор пары ключей передается аутентификатору, и тот, используя origin и идентификатор, найдет вашу пару ключей в своей защищенной БД и вернет подпись.
Альтернатива к передаче идентификатора это использование резидентных ключей (RK, resident keys). При аутентификации аутентификатор вернет подписи для всех RK пар ключей. Клиент предоставляет пользователю выбор пары и вернет подпись серверу. Более подробно RK я распишу ниже.
5. Аттестация
Пятый механизм это аттестация. Иногда сайту нужно узнать тип устройства у пользователя. Так например в США все государственные учреждения обязаны использовать только FIPS (Federal Information Processing Standards) сертифицированные устройства. Подобные требования есть во Франции, Израиле, России и других странах. Для всего этого и существует аттестация.
При производстве аутентификаторов, на каждые сто тысяч устройств компания генерирует «сертификат партии» и ключи к нему и устанавливает их на каждое устройство. При регистрации устройство подписывает всю информацию приватным ключом партийного сертификата и возвращает сертификат вместо публичного ключа. В сертификате содержится информация о аутентификаторе, и его AAGUID(Authenticator Attestation GUID). Также при получении FIDO сертификации компания выпускает специальный документ метадаты, или просто метадату, и помещает в наше хранилище метадаты доступное всем. В метадате содержится информация о аутентификаторе, включая его криптографические характеристики, биометрические характеристики если он поддерживает биометрику, алгоритмы, уровни безопасности, базовое описание и много другой информации. а основе имеющейся информации сервер может судить о том, стоит ли ему принимать аутентификатор или нет.
Аттестация бывает разная. Существует полная версия аттестации, в которой сервер возвращает сертификат. Есть само-аттестация, при которой устройство не поддерживает сертификаты, а вместо этого возвращает публичный ключ только что сгенерированной пары.
Также пользователь может сам настроить метод, с помощью которого он хочет вернуть аттестацию. Так например пользователь может вообще запретить возвращать аттестацию и клиент просто удалит её, вернув регистрационный ответ без аттестации. Об этом я расскажу позже.
6. Тест на наличие пользователя
Одно из фундаментальных требований FIDO это тест на наличие пользователя. В данном случае имеется в виду, что аутентификатор обязан удостоверится в присутствии пользователя… Это может быть сделано по-разному: простое нажатие на кнопку, отпечаток, пин-код и другое.
WebAuthn
В этой секции мы рассмотрим JS API для работы с FIDO2.
Credential Management API
WebAuthn это дополнения к Credential Management API для менеджмента учетных записей публичных ключей. CredMan API это API(неожиданно!) для менеджмента учетных данных пользователя или если выразиться проще: это API для доступа к автозаполнению в браузере.
Далее мы рассмотрим пример создания учетных данных:
А вот пример запроса учетных данных и последующего использования их для аутентификации:
Create public-key credential
Для создания Public-Key Credential мы будем использовать navigator.credentials.create метод, передав ему CreateCredential объект типа «publicKey».
Думаю, код говорит сам за себя, но отмечу при этом несколько моментов:
— challenge и user.id должны быть буферами
— pubKeyCredParams — это список алгоритмов, которые поддерживает сервер. В данный момент сертифицированные сервера FIDO2 обязаны поддерживать: RSA-PSS 2048 с SHA256/384/512, RSA-PKCS1_3 с SHA256/384/512/1, EC с SHA256/384/512, а также кривые secp256/384/521p1(NIST) и secp256k1, и EdDSA ED25519.
— attestation — это собственно вид аттестации, возвращаемой клиентом. Есть три возможные значения: none, direct, indirect. Direct это, собственно, классическая аттестация. None это полное отсутствие аттестации, при котором клиент просто удалит всю аттестационную секцию и заменит AAGUID в ответе на 0x00000000000000000000000000000000. Indirect это аттестация через privacy-ca. По-умолчанию attestation установлена на none. То есть если вы хотите аттестацию, то надо это чётко указать в параметрах. При этом необходимо учитывать, что пользователь все равно может вам отказать в аттестации и вернуть ‘none’ если он того захочет.
Вот пример пример того как пользователь может контролировать аттестацию в Firefox Nightly
В ответ вы получите аттестационный объект:
Здесь вы можете видеть:
— id/rawId — это идентификатор пары ключей на устройстве или credId. id это base64url закодированная версия буфера rawId.
— response.clientDataJSON — это буфер CollectedDataJSON, JSON объекта содержащего сессионную информацию и сам вызов. Пример декодированного clientDataJSON:
— attestationObject — это CBOR объект, содержащий аттестацию, информацию об аутентификаторе, флаги, счётчик и публичный ключ.
— authData — это сырой буфер, содержащий хеш источника или rpIdHash, флаги, счетчик, идентификатор пары ключей, блок с аттестационной информацией и информацию от расширений.
— fmt — это формат аттестации. В данный момент WebAuthn поддерживает «packed», «fido-u2f», «android», «tpm» и «safety-net» аттестации.
— attStmt — это собственно информация по аттестации. Подпись, сертификаты и так далее.
Для верификации подписи мы высчитываем хеш clientDataJSON и получаем clientDataHash. Затем мы объединяем authData и clientDataHash и получаем signatureBase. И в конце мы подтверждаем подпись с помощью attStmt.sig, сертификата или публичного ключа пользователя и signatureBase.
Get assertion
Для того чтобы получить аутентификационую подпись мы будем использовать navigator.credentials.create метод, передав ему объект типа «publicKey».
var randomChallengeBuffer = new Uint8Array(32);
window.crypto.getRandomValues(randomChallengeBuffer);
allowCredentials — это список разрешенных учетных записей, которые идентифицируются идентификатором пары ключей на устройстве (credId). Для двухфакторной аутентификации вы всегда обязаны передавать allowCredentials c credId в запросе. Если во время создания учетной записи мы установили флаг authenticatorSelection.requireResidentialKey, то в дальнейшем обязаны не добавлять поле allowCredentials.
В ответ получаем вот такой объект:
Как вы видите, структура очень похожа, но есть несколько различий:
— clientDataJSON.type теперь типа «webauthn.get»
— attestationObject отсутствует
— authenticatorData это authData, но теперь без authenticatorAttestation секции
— signature это подпись
— userHandle — это идентификатор пользователя, который вы передали во время регистрации в поле user.id
Вычисление подписи работает так же, как и при создании учетной записи.
UPD: Демо webauthn.org (Нужен U2F токен)
На этом я закончу первую часть из цикла статей. В следующей части мы разберем протокол общения клиента и аутентификатора CTAP2(Client-to-Authenticator 2).
Большая благодарность Павлу Замятину за редактуру и орфографию.
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 альянса, пишите в комментариях.