Новые стандарты для беспарольной аутентификации: как они работают

    На прошлой неделе были опубликованы два новых стандарта для беспарольной аутентификации на сайтах, в мобильных и веб-приложениях: WebAuthn API и CTAP. Оба были одобрены Microsoft, Mozilla и Google.

    Подробнее об них расскажем ниже.


    / Flickr / Mark Burnett / СС

    WebAuthn стал результатом коллаборации консорциумов W3C и FIDO Alliance. Первый занимается внедрением технологических стандартов для интернета, а второй — разработкой и совершенствованием надежных стандартов аутентификации в сети.

    Работа над стандартом WebAuthn началась еще в 2015 году, когда FIDO передали группу спецификаций FIDO2 консорциуму W3C. Последовавшие версии FIDO 2.0 Web API позволяют пользователям залогиниться в сервисах Google, Facebook, Dropbox, GitHub и другим, используя секретные токены.

    WebAuthn работает по тем же принципам, что и FIDO 2.0 Web API, однако поддерживает множество других способов аутентификации. Новый стандарт дает пользователям возможность идентифицировать себя в сетевых приложениях и на сайтах по отпечатку пальца, лицу, сетчатке глаза и другим биометрическим показателям.

    Также FIDO Alliance был разработан новый протокол аутентификации CTAP (Client-to-Authenticator Protocol), позволяющий идентифицировать пользователей помощью внешних ключей безопасности (например, USB-ключей) или мобильных устройств.

    Стандарты уже утвердили представители Microsoft, Apple, Google, PayPal и др. Это означает, что вскоре их начнут интегрировать в ИТ-экосистему. В частности, консорциум W3C уже призвал разработчиков начать работу над реализациями WebAuthn.


    / Flickr / Christiaan Colen / CC

    Принцип работы WebAuthn


    Последовательность действий пользователя при аутентификации с помощью нового стандарта следующая:

    1. Пользователь через компьютер или ноутбук заходит на сайт example.ru и видит опцию «Войти с помощью телефона».
    2. Пользователь выбирает эту опцию и получает сообщение от браузера «Пожалуйста, выполните вход на своем телефоне».
    3. На телефон приходит уведомление «Войти на сайт example.ru».
    4. При нажатии на уведомление появляется список аккаунтов, из которого выбирается нужный.
    5. Далее, идет запрос авторизации (отсканировать палец, ввести PIN-код и т. д.), и в случае успеха сайт открывается на компьютере/ноутбуке.

    Данные входа принадлежат пользователю, а управляются аутентификатором, с которым через браузер и ОС взаимодействует сервис, использующий WebAuthn. С помощью скриптов выполняются операции создания новых данных для входа или реализуется аутентификация по уже существующим. Скрипты не имеют доступа к данным пользователя, а только получают информацию о них в виде объектов.

    В основе стандарта лежат два базовых метода, отвечающих за регистрацию и вход в систему: navigator.credentials.create() и navigator.credentials.get(). С их помощью WebAuthn регистрирует данные входа (credentials) на сервере, а затем используют их для проверки «подлинности» пользователя.

    • Navigator.credentials.create() создает реквизиты доступа либо при регистрации аккаунта, либо для ассоциации новой асимметричной пары ключей с уже существующим аккаунтом.
    • Navigator.credentials.get() использует уже известные реквизиты доступа для аутентификации на сервисе.

    Оба метода требуют защищенного соединения (например, https). По сути, во время работы они получают от сервера длинное число, которое называется challenge, а затем передают его обратно, подписав закрытым ключом. Это доказывает серверу, что пользователь имеет необходимый для аутентификации закрытый ключ. Поэтому раскрывать дополнительные секреты по сети нет необходимости.

    При этом данные пользователей для входа ассоциируются с уникальным ID. Этот ID затем передается клиентом аутентификатору при каждой операции, чтобы убедиться, что все проходит исключительно в рамках идентифицированного сервиса.

    О протоколе CTAP


    Протокол CTAP концептуально состоит из трех уровней: Authenticator API, Message Encoding и Transport-specific Binding.

    На уровне абстракции Authenticator API, каждая операция определяется как API-вызов — принимает входные параметры и возвращает результат (или ошибку). Здесь используются следующие методы: authenticatorMakeCredential для генерации новых входных данных, authenticatorGetAssertion для подтверждения аутентификации и authenticatorCancel для отмены всех текущих операций.

    На уровне Message Encoding осуществляется формирование и шифрование всех запросов к Authenticator API. Хост должен создать и зашифровать запрос и отправить его аутентификатору с использованием выбранного транспортного протокола.

    Что касается уровня Transport-specific Binding, то здесь запросы и ответы передаются внешним аутентификаторам с использованием USB, NFC, Bluetooth и др.

    Кто внедряет


    В 60-м релизе Firefox и 67-м релизе Chrome (выходят в мае) будет поддержка WebAuthn. Microsoft еще в феврале анонсировали эту спецификацию в браузере Edge и Windows Hello, встроенной системе проверки подлинности учетных данных.

    В компаниях убеждены, что нововведения в браузерах позволят повысить защиту от фишинга, атак посредника (MITM) и атак повторного воспроизведения.

    Apple пока еще никак не комментировали поддержку стандарта в Safari, однако часть её инженеров входит в состав рабочей группы WebAuthn. Поэтому можно ожидать, что новости о внедрении новых стандартов появятся в скором времени.

    Майкл Джонс (Michael Jones), директор по партнерским отношениям Microsoft и один из редакторов спецификации WebAuthn, отметил: «Внедрение WebAuthn это большой шаг к практичной, прочной и надежной в области сохранения аутентификационных данных в сети».

    Несколько материалов из нашего корпоративного блога:

    1cloud.ru

    176,68

    IaaS, VPS, VDS, Частное и публичное облако, SSL

    Поделиться публикацией

    Похожие публикации

    Комментарии 68
      –4

      Определитесь, пожалуйста, WebAuthn или WinAuthn.

        0
        Ссылка на стандарт: Web Authentication specification (WebAuthn)
        +1
        > Пользователь выбирает эту опцию и получает сообщение от браузера «Пожалуйста, выполните вход на своем телефоне».
        > На телефон приходит уведомление «Войти на сайт example.ru».

        Сайт узнает на какой телефон отправить уведомления телепатически?
        Дико раздражают эти недосказанности.
          0

          Видимо они и так знают что это вы и у вас чайник кипит на кухне, просто авторизация для видимости )

            0
            Видимо они и так знают что это вы и у вас чайник кипит на кухне, просто авторизация для
            убедиться, что это не сосед в гости зашел.
              0
              товарищ майор инклюдет :)
              0
              Тут описан процесс аутентификации. Вероятно, до него необходимо зарегистрироваться. При регистрации смартфон привязывается к пользователю. По крайней мере так работает аутентификация смартфоном, которую я настраивал.
                0
                Технология предлагает отдать авторизацию по телефону в управление одной компании? (монополизация)
                Или каждый желающий будет делать свое, но со стандартным протоколом? (тогда выбирать не просто «по телефону», а еще и фирму-поставщика сервиса авторизации). Это не намного лучше чем oAuth. Владение телефоном не гарантирует, а только то, что телефон когда то имел некий номер.
                  +1

                  Делать свое но со стандартным протоколом

                0

                Это пример. Фидо не регламентирует как вы будете использовать на протокол, только сам протокол.

                +4
                когда FIDO передали веб-API фреймворка аутентификации
                «FIDO (Fast IDentity Online)»
                /me выдохнул
                  0

                  Гипертекстовая-ламповая-аутентификация

                  +5

                  Всем привет. Я собственно ответственный за техническую сертификацию в FIDO. Буду рад ответить на любые вопросы


                  Так же хочу заметить что у меня есть слайды по WebAuthn http://slides.com/herrjemand/webauthn-isig


                  Так же у нас есть воршоп, вот слайды https://slides.com/fidoalliance/jan-2018-fido-seminar-webauthn-tutorial#/


                  И собственно демо к воркшопу
                  https://github.com/fido-alliance/webauthn-demo

                    +1
                    Приветствую herrjemand
                    Новый стандарт дает пользователям возможность идентифицировать себя в сетевых приложениях и на сайтах по отпечатку пальца, лицу, сетчатке глаза и другим биометрическим показателям.
                    В каком виде хранятся и используются «биометрические показатели»?

                    Последовательность следующая:
                    1. Пользователь на сайт example.ru и выбирает опцию «Войти с помощью телефона».
                    2. Пользователь получает сообщение от браузера «выполните вход на своем телефоне».
                    3. На телефон приходит уведомление «Войти на сайт example.ru».
                    4. Выбрать аккаунтна телефоне.
                    5. Запрос авторизации (сканировать палец, ввести PIN-код и т. д.)
                    Всем сайтам доступен особый кукисайди прочитав который сайт знает на какой телефон слать?
                    Что за пин-код?

                    Как это работает в случае с USB токеном или встроенным сканером в ноут/комп?
                      0

                      Здравствуйте TrllServ *)


                      В каком виде хранятся и используются «биометрические показатели»?

                      В SEP/TPM.


                      Всем сайтам доступен особый кукисайди прочитав который сайт знает на какой телефон слать?

                      Это один из возможных сценариев использования протокола через push-notifications. Это не описано в самом протоколе.


                      Что за пин-код?

                      Аутентификатор может иметь устройство ввода пин-кода, на пример мобильный, или аутентификатор с экраном. Или пин код вводит на клиентском интерфейсе, на пример браузер, и через протокол ввода пин кода активировать аутентификатор https://fidoalliance.org/specs/fido-v2.0-ps-20170927/fido-client-to-authenticator-protocol-v2.0-ps-20170927.html#authenticatorClientPIN


                      Как это работает в случае с USB токеном или встроенным сканером в ноут/комп?

                      Через USB HID интерфейс.

                        0
                        Всем сайтам доступен особый ID
                        Это один из возможных сценариев использования протокола через push-notifications. Это не описано в самом протоколе.
                        В данном случае меня интересует ПК/ноут направление. А если точнее безопасность.
                        Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?
                          0

                          Собственно два места где что-то хранится это сервер и аутентификатор:


                          На сервере хранится


                          • credID — это уникальный идентификатор пары ключей на устройстве
                          • публичный ключ — собственно публичный ключ вашей регистрационной пары

                          На устройстве в безопасной памяти хранится приватный ключ который используется для подписи вызова(challenge) и идентифицируется с помощью credID.


                          Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?

                          Это не часть протокола. Как это сделано в различных имплементациях уже дело к имплементации

                      0
                      При этом данные пользователей для входа ассоциируются с уникальным ID. Этот ID затем передается клиентом аутентификатору при каждой операции, чтобы убедиться, что все проходит исключительно в рамках идентифицированного сервиса.


                      Я один продолжаю видеть так и не закрытую дыру в этом действии? Простой сниффер ловит строки с этим ID и отправляет свои запросы с этим же ID, представляясь пользователем из этой сессии.
                      Реальная защита на данный момент, это на каждый запрос, генерация новой пары, с вводом пина на исходящем устройстве (как вебмани например сейчас на мобильной платформе делают).
                      Да, это немного раздражает пользователя, но зато сильно затрудняет отлов транзитного трафика и его подмену.
                        0

                        На устройство передается origin и id. Если пользователь подвергается фишингу, то origin будет иным и таким методом фишинга будет повержен.


                        https://slides.com/herrjemand/webauthn-isig#/18

                        0
                        Добрый день, herrjemand!

                        Не могли бы вы рассказать подробнее о совместимости с U2F-устройствами, а также требуется ли аттестация таких устройств для webauthn-серверов?
                        И если аттестация устройств происходит, то используется ли ECDAA?
                      0
                      Круто что добавляют в стандарт) и очень напомнило authenticator blizzard :)
                        0
                        Эта система в принципе может работать если у нас локальная сеть БЕЗ выхода в интернет?
                        Как решается (и кем? Сайт на котором выполняется авторизация?) кто может быть 'провайдером авторизации'. Вот допустим хочу я в свой аккаунт гугл входить пользуюсь выданным мне как сотруднику российской полугосударственной структуры токеном?(Допустим и токен поддерживает этот стандарт и гугл поддерживает, но никаких особых отношений доверия между этой структурой и гуглом — нет).
                          +1

                          Как вы войдете а гугл аккаунт без интернета?

                            0
                            Речь про два разных сценария:
                            — нет интернета (или нет связи с гуглом) но есть внутренний сайт на котором хочется авторизоваться.
                            — интернет есть но хочется авторизоваться на гугле токеном выданном тем кто с гуглос отношений официальных иметь не может.

                            Судя по статье — ответ на оба вопроса — 'да', но хотелось бы подтверждения.
                              0

                              Мне кажется что все жти стандарты это еще один шаг к тотальному контролю над сетью. А для внутреннего использования некто не мешает прямо скйчас использовать к примеру google authenticator с одноразовыми токенами.

                                0

                                Он не требует доступа к интернету

                              0
                              Какой гугл без интернета)))
                              0

                              Аутентификатор это USB/NFC/HID устройство. Интернет ему не нужен. Собственно купите U2F токен и запустите наше демо без интернета *)


                              https://github.com/fido-alliance/webauthn-demo

                              0

                              Что делать в случае утраты телефона?
                              Скорее перевыпускать симкарту или предусмотрена поддержка пароля + телефона?

                                +1

                                В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификатор. Думайте о аутентификаторах как о ключах от дома. У вашей жени, бабушки, мамы, под помидорами в саду есть запасные ключи. Так же с аутентификаторами *)

                                  0
                                  В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификатор
                                  Не лучшее решение.
                                  Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.
                                  С ключами так-то попроще, положил на полку и забыл до ситуации Ч.
                                    0
                                    Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.

                                    Аутентификатором может быть и телефон, и ключ, и ноутбук.


                                    Зарегестрировался на телефоне. Добавил свой ключ, и положил на полку/в сейф

                                      0
                                      Не обязательно пополнять, можно просо принимать входящие чтобы не отключили. У меня йота так как купил 1 раз заплатил за месяц, так и пользуюсь 5 лет уже, там даже тариф безлимитного инета остался, которых сейчас нет в природе.
                                        0
                                        Не уверен на счёт йоты, но другие операторы блочат симки при отсутствии трат за 89-90 дней.
                                  0
                                  Это то, о чем я подумал? Конец запоминанию сотни разных паролей? Если так, то жду с нетерпением.
                                    –1
                                    и видит опцию «Войти с помощью телефона».
                                    Когда я пробовал стать пользователем Telegram, то как раз на этой стадии решил отказаться от этой затеи.
                                    Неужели нет никакой бестелефонной процедуры, которая не деанонимизировала бы пользователя? Ну почему же — есть, например в Токсе (и не только в нём). Но разрабы почему-то предпочитают не замечать этой возможности.
                                      +1

                                      Не имеется ввиду использовать телефонный номер. Имеется ввиду использовать телефон(устройство), и его криптографические возможности как аутентификатор.

                                        0
                                        Не понял! Как можно использовать телефон, не задействуя его номер? Тем более что в статье прямо указано использовать телефон не как криптографическое устройство, а как приёмник сообщений (по сети мобильной связи, надо полагать):
                                        На телефон приходит уведомление «Войти на сайт example.ru»
                                        А такое использование — это автоматическая деанонимизация владельца.
                                          0

                                          В статье пример использования WebAuthn в контексте одного приложения одной компании. Вот лучше пример того что пытались сказать в статье:


                                          • Вы регистрируетесь в банке на компьютере
                                          • Скачиваете банковский клиент на телефон и проходите аутентификацию
                                          • В следующий раз когда вы заходите в банк на компьютере, на телефоне вы получаете уведомление о том что вы хотите зайти.
                                          • Вы подтверждаете
                                          • Проффит

                                          Как видите нигде телефонный номер не был использован

                                            –2
                                            Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?

                                            Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.

                                            Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
                                              +1
                                              Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.

                                              Одноразовые пароли через СМС ужасный второй фактор. Советую почитать мою статью по U2F https://habrahabr.ru/post/305508/

                                                +1
                                                Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?

                                                Сайты могут использовать метод аутентификации, который им нравится. Но среди прочих, они смогут выбрать то решение по аутентификации, которое построено на стандартизированных протоколах. Соответствие стандартам позволяет понимать, что именно и как работает. Иначе может получиться ситуация которую я недавно видел в одном банке: одна компания предложила аутентификацию с использовнием push сообщений для уведомления пользователя по аналогии с тем, что написано в статье. То есть на смартфон приходит уведомление о том, что надо аутентифицироваться или подписать транзакцию (с текстовым описанием самой транзакции). Пользователь открывает приложение для аутентификации и вводом пин-кода, отпечатком пальца или FaceID подтверждает аутентификацию (подписывает нонс закрытым ключом и отправляет на сервер аутентификации). А конкуренты предложили просто присылать по каналу push одноразовые коды. Это вообще нельзя рассматривать как конкурирующие методы аутентификации. Но для клиента не всегда понятно, в чем разница, если и там и там push.
                                                Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.

                                                Что именно происходит при аутентификации в приват24 я не знаю. Но вы явно не просто камерой снимаете, а используете мобильное приложение банка, которое скорее всего тоже использует асимметричную криптографию для подтверждения входа.
                                                Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.

                                                Замечу, что нет метода аутентификации, который бы гарантировал факт владением номера. СМС вообще крайне не рекомендуется к использованию для аутентификации.
                                                В приведенных примерах вы доказываете факт владения закрытым ключом (на смартфоне, на аппаратном носителе или еще на чем-то), что и является фактором.
                                                  0
                                                  Я понял, что вы предлагаете хранить приватный ключ (которого можно сделать копию) в приложении на телефоне, но я не понял какой смысл в стандартизации протокола? Сайты будут закладывать такую реализацию, которая и для них удобна и для пользователя безопасна.
                                                  В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.
                                                  Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.
                                                  Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.
                                                    +1
                                                    Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.

                                                    Практически все новые телефоны всех классов имею SEP и считыватель отпечатков


                                                    Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.

                                                    Пароль это статическое значение. Подпись приватным ключом это уникальный идентификатор на каждый вызов


                                                    Сайты будут закладывать такую реализацию, которая и для них удобна и для пользователя безопасна.

                                                    FIDO2 удобнее и безопаснее


                                                    Я понял, что вы предлагаете хранить приватный ключ (которого можно сделать копию) в приложении на телефоне

                                                    Приватные ключи хранятся в SEP либо в худшем случае в keychain на системном уровне, для извлечения которых нужно минимум рутировать телефон не говоря о их расшифровке


                                                    какой смысл в стандартизации протокола?

                                                    Потому что аутентификация слишком критичный элемент безопасности интернета чтобы оставлять его разработчикам. Когда TLS/SSL выходил люди говорили тоже самое.

                                                      0
                                                      Как уже многократно упоминалось, вы вольны выбирать, какой носитель аутентификатора использовать.
                                                      Я привел пример, когда вы можете видеть использование одной и той же технологии (push) при аутентификации. И там и там push. Но методы то совсем разные.
                                                      Это как если вам нужно использовать шифрование: вы можете использовать стандартный алгоритм AES, а можете взять какой-то алгоритм, который не стандартизован, но зато придуман вами и является на ваш взгляд более надежным.
                                                      В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.

                                                      Ну вот вы не видите, что происходит, а пока вы держите телефон, приложение отправляет на сервер приват24 информацию, что вы — аутентифицированный пользователь. Я предполагаю, что в этот момент общение между приложением и сервером примерно такое:
                                                      1. приложение сообщает серверу, что хочет аутентифицировать пользователя.
                                                      2. Сервер отправляет нонс
                                                      3. Приложение его подписывает закрытым ключом и возвращает ответ серверу.
                                                      4. Сервер проверяет подпись.

                                                      Фактор владения байтами (приватный ключ) не больше фактора знания пароля

                                                      Есть разные угрозы. От подсматривания, кейлоггеров или даже от утечки на стороне поставщика услуг мобильное приложение с закрытым ключом более предпочтительно, чем парольная аутентификация.
                                                      Говорить, что какой-то фактор больше или меньше другого, некорректно. Тем более, что даже в приведенном мной примере можно использовать PIN-код(аналог пароля) для доступа к закрытому ключу. А значит, что это уже двухфакторная аутентификация.
                                                        0
                                                        1. Вы конечно сравнили… AES это блочный аглоритм шифрования, грубо говоря одна функция (на входе блок байтов фиксированной длинны, на выходе такойже длины, но других). А тут хотят стандартизировать целую цепочку запросов между 3 сущностями.
                                                        2. Врятли все так сложно. Скорее всего телефон по SSL отправляет «пользователь с ID сессии хочет зайти через браузер, ID сессии в браузере». И в принципе серверу нет причин не доверять, в своем же приложении он уже аутетифицировал пользователя, тоже самое можно и в браузере сделать.
                                                          0

                                                          Серверу есть причина никому не доверять как и клиенту есть причина никому не доверять. Интернет это дикий запад.


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


                                                          Как железные дороги покорили дикий запад, так и мы убьем фишинг.

                                                            0
                                                            Гарантировать подобное можно только, если гарантируете, что приватный ключ в аутентификаторе невозможно скопировать. Даже если добьетесь поддержки хранения ключа внутри ОС устройства, то всеравно останется рутование и уязвимости. Только прошиваемый, нечитаемый ключ внутри проца поможет (вроде симки так делают).
                                                              0

                                                              В большинстве новых смартфонов есть SEP. Если есть считыватель отпечатков то там гарантированно есть SEP

                                                  0
                                                  Скачиваете банковский клиент на телефон и проходите аутентификацию…
                                                  … Как видите нигде телефонный номер не был использован
                                                  Кажется, начинаю понимать: имеется ввиду связь не через сети мобильного оператора, а обычный интернет, доступный через любой публичный вайфай. Действительно, тогда не нужен ни номер, ни активная сим-карта в аппарате. Более того, и сам телефон не нужен — достаточно любого компа, подключённого в интернет.
                                          +2

                                          В связи с оживленным интересом к протоколу, я за пару дней напишу статью, где я более технически разъясню все аспекты. На все что вы бы хотели видеть ответы пишите здесь *)

                                            –1
                                            Тут уже много каментов с вопросами, часть без ответа.
                                            Возможно, вы не живете в РФ, но тут сим-картномера по паспорту, а за не использование(не пополнение) 90 или 180 дней отключение. И такой способ заметно усложнит, а не упростит.
                                            Способ хранения как было сказано «Это не часть протокола», но должен быть, иначе не правильная реализация поставит крест на безопасности.
                                            Стандарт нужно дорабатывать.
                                              0

                                              Стандарт не может диктовать требования к хранилищу аутентификаторов, это уже дело сертификации. В FIDO у нас есть:


                                              • L1 — техническая сертификация + минимальный аудит безопасности
                                              • L2/3/4 — L1 + пентестинг + аудит лабораториями + куча всего другого для прохождения FIPS1/140 etc

                                              Так что пользуйтесь сертифицированными продуктами *)

                                                –1
                                                Так что пользуйтесь сертифицированными продуктами
                                                Правильные пароли и отсутствие ленности в вопросах безопасности делают не интересной, лично для меня, эту технологию. Т.е. использовать не планирую.

                                                А вот вопросы безопасности и возможные утечки всё еще интересуют, но как я понимаю это надо смотреть в релизах соответствующих версий браузеров.
                                              0
                                              Пользователь через компьютер или ноутбук заходит на сайт example.ru и видит опцию «Войти с помощью телефона».

                                              То есть сайт example.ru определяет, что пользователь может входить только через его мобильное приложение? И через USB-HID устройство войти нельзя или стандарт обязывает принимать любой "Аутентификатор"?

                                                0

                                                Пользователь может иметь множество зарегистрированных аутентификаторов.

                                                0
                                                Ещё один вопрос. Идентификация пользователя через его телефон — вы уверяете, что пользователь при этом не деанонимизируется, поскольку телефонный номер (т.е. активная сим-карта, привязанная оператором сотовой связи к определённым паспортным данным) не используется. Но тогда остаётся только идентификация по IMEI, т.е. привязка по факту покупки этого конкретного телефона. А если телефон будет потерян или украден?
                                                Нет, всё-таки есть тут что-то неправильное, неудобное… Ещё раз напоминаю — есть примеры, что в деле аутентификации можно обойтись вообще без телефона. Для меня они предпочтительнее: как ни крути, а телефон — это легальный шпион, постоянно носимый с собою.
                                                  0

                                                  Смотрите. Я смотрю на телефон как на еще один аутентификатор. Так же у меня есть железные аутентификаторы от компаний Yubico и Feitian. Так же у меня есть ноутбук со считывателем отпечатков и SGX.


                                                  Это как в песне: Аутентификаторы бывают разные, биометрические, мобильные, железные, встроенные, разныыыыеее *)

                                                    0
                                                    Я смотрю на телефон как на еще один аутентификатор.
                                                    Допустим.
                                                    Но как быть если я захожу на сайт через свой телефон?
                                                    Захожу с телефона, и на телефон приходи авторизация?
                                                    Учитывая статистику прошлого года, тех кто сидит с телефона большую часть времени уже больше половины, и это очень актуальный вопрос.
                                                      0

                                                      Я уже объяснял что это неудачный пример из сией статьи. Есть различные подходы к процессу аутентификации которые мы не регламентируем. Это дело каждой отдельной имплементации

                                                0
                                                О, переизобрели Enum, которому 15 лет в обед.
                                                  0

                                                  Enum это OTP решение, так что не переизобрели. Больше как переизобрели клиентские сертификаты

                                                  0
                                                  Сразу вспоминается механика входа на icloud.com с компа под своим appleID:
                                                  Открываешь сайт, вводишь appleID с паролем.
                                                  на телефоне, подвязанному к этому appleID, высвечивается OTP ключ для продолжения процедуры входа на сайт
                                                  ну и письмо на icloud.com, что был вход.

                                                  я не говорю что это плохо. Это круто и красиво, менеджер паролей в облаках + вторая аутентификация. Просто это не «космос», это уже есть.
                                                    0
                                                    Может вопрос глупый, но задам. Не возникнет проблем с аккаунтом, которым пользуются несколько человек?
                                                      0

                                                      Не совсем понял ваш вопрос

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое