На прошлой неделе были опубликованы два новых стандарта для беспарольной аутентификации на сайтах, в мобильных и веб-приложениях: 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 это большой шаг к практичной, прочной и надежной в области сохранения аутентификационных данных в сети».

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

Комментарии (60)


  1. staticlab
    22.04.2018 21:44
    +1

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


  1. Ostan
    22.04.2018 22:04

    Ссылка на стандарт: Web Authentication specification (WebAuthn)


    1. herrjemand
      23.04.2018 02:24

  1. Apache02
    23.04.2018 00:33

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

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


    1. zim32
      23.04.2018 09:08

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


      1. TrllServ
        23.04.2018 09:18

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


      1. kalininmr
        24.04.2018 00:14

        товарищ майор инклюдет :)


    1. nmk2002
      23.04.2018 12:18

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


      1. Apache02
        23.04.2018 15:23

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


        1. herrjemand
          23.04.2018 18:31

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


    1. herrjemand
      23.04.2018 18:30

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


  1. pda0
    23.04.2018 01:20

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


    1. herrjemand
      23.04.2018 18:31

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


  1. herrjemand
    23.04.2018 02:23

    Всем привет. Я собственно ответственный за техническую сертификацию в 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. TrllServ
      23.04.2018 08:51

      Приветствую herrjemand

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

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

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


      1. herrjemand
        23.04.2018 13:37

        Здравствуйте 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 интерфейс.


        1. TrllServ
          23.04.2018 13:46

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


          1. herrjemand
            23.04.2018 14:49

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


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


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

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


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

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


  1. sstv
    23.04.2018 05:04

    Круто что добавляют в стандарт) и очень напомнило authenticator blizzard :)


  1. vikarti
    23.04.2018 10:30

    Эта система в принципе может работать если у нас локальная сеть БЕЗ выхода в интернет?
    Как решается (и кем? Сайт на котором выполняется авторизация?) кто может быть 'провайдером авторизации'. Вот допустим хочу я в свой аккаунт гугл входить пользуюсь выданным мне как сотруднику российской полугосударственной структуры токеном?(Допустим и токен поддерживает этот стандарт и гугл поддерживает, но никаких особых отношений доверия между этой структурой и гуглом — нет).


    1. zim32
      23.04.2018 11:18
      +1

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


      1. vikarti
        23.04.2018 13:25

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

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


        1. zim32
          24.04.2018 11:40

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


          1. zim32
            24.04.2018 11:41

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


    1. herrjemand
      23.04.2018 13:39

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


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


  1. eduard93
    23.04.2018 14:32

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


    1. herrjemand
      23.04.2018 14:43
      +1

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


      1. TrllServ
        23.04.2018 20:10

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


        1. herrjemand
          23.04.2018 21:51

          Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.

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


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


        1. bro-dev
          23.04.2018 22:53

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


          1. sumanai
            24.04.2018 00:33

            Не уверен на счёт йоты, но другие операторы блочат симки при отсутствии трат за 89-90 дней.


  1. lxsmkv
    23.04.2018 16:17

    Это то, о чем я подумал? Конец запоминанию сотни разных паролей? Если так, то жду с нетерпением.


  1. nehrung
    23.04.2018 19:41

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


    1. herrjemand
      23.04.2018 21:52

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


      1. nehrung
        23.04.2018 23:30

        Не понял! Как можно использовать телефон, не задействуя его номер? Тем более что в статье прямо указано использовать телефон не как криптографическое устройство, а как приёмник сообщений (по сети мобильной связи, надо полагать):

        На телефон приходит уведомление «Войти на сайт example.ru»
        А такое использование — это автоматическая деанонимизация владельца.


        1. herrjemand
          24.04.2018 00:04

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


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

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


          1. Apache02
            24.04.2018 04:01

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

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

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


            1. herrjemand
              24.04.2018 11:58
              +1

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

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


            1. nmk2002
              24.04.2018 15:49
              +1

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

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

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

              Замечу, что нет метода аутентификации, который бы гарантировал факт владением номера. СМС вообще крайне не рекомендуется к использованию для аутентификации.
              В приведенных примерах вы доказываете факт владения закрытым ключом (на смартфоне, на аппаратном носителе или еще на чем-то), что и является фактором.


              1. Apache02
                24.04.2018 16:31

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


                1. herrjemand
                  24.04.2018 16:47
                  +1

                  Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.

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


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

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


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

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


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

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


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

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


                1. nmk2002
                  24.04.2018 17:03

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

                  В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.

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

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

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


                  1. Apache02
                    24.04.2018 18:52

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


                    1. herrjemand
                      24.04.2018 19:23

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


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


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


                      1. Apache02
                        24.04.2018 19:30

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


                        1. herrjemand
                          24.04.2018 19:44

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


          1. nehrung
            24.04.2018 11:50

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


            1. herrjemand
              24.04.2018 11:59

              Именно!


  1. herrjemand
    23.04.2018 21:56

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


    1. TrllServ
      24.04.2018 06:13

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


      1. herrjemand
        24.04.2018 12:02

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


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

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


        1. TrllServ
          25.04.2018 10:51
          -1

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

          А вот вопросы безопасности и возможные утечки всё еще интересуют, но как я понимаю это надо смотреть в релизах соответствующих версий браузеров.


    1. kITerE
      24.04.2018 10:43

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

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


      1. herrjemand
        24.04.2018 12:03

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


    1. nehrung
      24.04.2018 12:11

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


      1. herrjemand
        24.04.2018 12:22

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


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


        1. TrllServ
          25.04.2018 10:59

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


          1. herrjemand
            25.04.2018 11:05

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


  1. DjOnline
    24.04.2018 19:43

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


    1. herrjemand
      25.04.2018 11:06

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