Comments 68
Editorial version https://w3c.github.io/webauthn/
> На телефон приходит уведомление «Войти на сайт example.ru».
Сайт узнает на какой телефон отправить уведомления телепатически?
Дико раздражают эти недосказанности.
Видимо они и так знают что это вы и у вас чайник кипит на кухне, просто авторизация для видимости )
Или каждый желающий будет делать свое, но со стандартным протоколом? (тогда выбирать не просто «по телефону», а еще и фирму-поставщика сервиса авторизации). Это не намного лучше чем oAuth. Владение телефоном не гарантирует, а только то, что телефон когда то имел некий номер.
Это пример. Фидо не регламентирует как вы будете использовать на протокол, только сам протокол.
когда FIDO передали веб-API фреймворка аутентификации«FIDO (Fast IDentity Online)»
/me выдохнул
Всем привет. Я собственно ответственный за техническую сертификацию в 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. Пользователь на сайт example.ru и выбирает опцию «Войти с помощью телефона».
2. Пользователь получает сообщение от браузера «выполните вход на своем телефоне».
3. На телефон приходит уведомление «Войти на сайт example.ru».
4. Выбрать аккаунтна телефоне.
5. Запрос авторизации (сканировать палец, ввести PIN-код и т. д.)
Что за пин-код?
Как это работает в случае с USB токеном или встроенным сканером в ноут/комп?
Здравствуйте 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 интерфейс.
В данном случае меня интересует ПК/ноут направление. А если точнее безопасность.Всем сайтам доступен особый IDЭто один из возможных сценариев использования протокола через push-notifications. Это не описано в самом протоколе.
Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?
Собственно два места где что-то хранится это сервер и аутентификатор:
На сервере хранится
- credID — это уникальный идентификатор пары ключей на устройстве
- публичный ключ — собственно публичный ключ вашей регистрационной пары
На устройстве в безопасной памяти хранится приватный ключ который используется для подписи вызова(challenge) и идентифицируется с помощью credID.
Как именно будет определяться, что будет храниться у пользователя? Или пуш уведомления станут встроенными и не отключаемы в браузере как на мобильных(без специальных знаний)?
Это не часть протокола. Как это сделано в различных имплементациях уже дело к имплементации
При этом данные пользователей для входа ассоциируются с уникальным ID. Этот ID затем передается клиентом аутентификатору при каждой операции, чтобы убедиться, что все проходит исключительно в рамках идентифицированного сервиса.
Я один продолжаю видеть так и не закрытую дыру в этом действии? Простой сниффер ловит строки с этим ID и отправляет свои запросы с этим же ID, представляясь пользователем из этой сессии.
Реальная защита на данный момент, это на каждый запрос, генерация новой пары, с вводом пина на исходящем устройстве (как вебмани например сейчас на мобильной платформе делают).
Да, это немного раздражает пользователя, но зато сильно затрудняет отлов транзитного трафика и его подмену.
Не могли бы вы рассказать подробнее о совместимости с U2F-устройствами, а также требуется ли аттестация таких устройств для webauthn-серверов?
И если аттестация устройств происходит, то используется ли ECDAA?
U2F преобразуется в CTAP2
Да, FIDO2 сервера должны будут поддерживать U2F аттестацию. Вот пример обработки U2F аттестации в FIDO2 https://github.com/fido-alliance/webauthn-demo/blob/master/utils.js#L196
Как решается (и кем? Сайт на котором выполняется авторизация?) кто может быть 'провайдером авторизации'. Вот допустим хочу я в свой аккаунт гугл входить пользуюсь выданным мне как сотруднику российской полугосударственной структуры токеном?(Допустим и токен поддерживает этот стандарт и гугл поддерживает, но никаких особых отношений доверия между этой структурой и гуглом — нет).
Как вы войдете а гугл аккаунт без интернета?
— нет интернета (или нет связи с гуглом) но есть внутренний сайт на котором хочется авторизоваться.
— интернет есть но хочется авторизоваться на гугле токеном выданном тем кто с гуглос отношений официальных иметь не может.
Судя по статье — ответ на оба вопроса — 'да', но хотелось бы подтверждения.
Аутентификатор это USB/NFC/HID устройство. Интернет ему не нужен. Собственно купите U2F токен и запустите наше демо без интернета *)
Что делать в случае утраты телефона?
Скорее перевыпускать симкарту или предусмотрена поддержка пароля + телефона?
В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификатор. Думайте о аутентификаторах как о ключах от дома. У вашей жени, бабушки, мамы, под помидорами в саду есть запасные ключи. Так же с аутентификаторами *)
В случае утраты аутентификатора(пример телефон), следует иметь запасной аутентификаторНе лучшее решение.
Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.
С ключами так-то попроще, положил на полку и забыл до ситуации Ч.
Обязывает иметь 2 номера. Причем если не пользуешься вторым, не забывать пополнять каждые 5 месяцев, что б не отключили.
Аутентификатором может быть и телефон, и ключ, и ноутбук.
Зарегестрировался на телефоне. Добавил свой ключ, и положил на полку/в сейф
и видит опцию «Войти с помощью телефона».Когда я пробовал стать пользователем Telegram, то как раз на этой стадии решил отказаться от этой затеи.
Неужели нет никакой бестелефонной процедуры, которая не деанонимизировала бы пользователя? Ну почему же — есть, например в Токсе (и не только в нём). Но разрабы почему-то предпочитают не замечать этой возможности.
Не имеется ввиду использовать телефонный номер. Имеется ввиду использовать телефон(устройство), и его криптографические возможности как аутентификатор.
На телефон приходит уведомление «Войти на сайт example.ru»А такое использование — это автоматическая деанонимизация владельца.
В статье пример использования WebAuthn в контексте одного приложения одной компании. Вот лучше пример того что пытались сказать в статье:
- Вы регистрируетесь в банке на компьютере
- Скачиваете банковский клиент на телефон и проходите аутентификацию
- В следующий раз когда вы заходите в банк на компьютере, на телефоне вы получаете уведомление о том что вы хотите зайти.
- Вы подтверждаете
- Проффит
Как видите нигде телефонный номер не был использован
Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
Одноразовые пароли через СМС ужасный второй фактор. Советую почитать мою статью по U2F https://habrahabr.ru/post/305508/
Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?
Сайты могут использовать метод аутентификации, который им нравится. Но среди прочих, они смогут выбрать то решение по аутентификации, которое построено на стандартизированных протоколах. Соответствие стандартам позволяет понимать, что именно и как работает. Иначе может получиться ситуация которую я недавно видел в одном банке: одна компания предложила аутентификацию с использовнием push сообщений для уведомления пользователя по аналогии с тем, что написано в статье. То есть на смартфон приходит уведомление о том, что надо аутентифицироваться или подписать транзакцию (с текстовым описанием самой транзакции). Пользователь открывает приложение для аутентификации и вводом пин-кода, отпечатком пальца или FaceID подтверждает аутентификацию (подписывает нонс закрытым ключом и отправляет на сервер аутентификации). А конкуренты предложили просто присылать по каналу push одноразовые коды. Это вообще нельзя рассматривать как конкурирующие методы аутентификации. Но для клиента не всегда понятно, в чем разница, если и там и там push.
Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.
Что именно происходит при аутентификации в приват24 я не знаю. Но вы явно не просто камерой снимаете, а используете мобильное приложение банка, которое скорее всего тоже использует асимметричную криптографию для подтверждения входа.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.
Замечу, что нет метода аутентификации, который бы гарантировал факт владением номера. СМС вообще крайне не рекомендуется к использованию для аутентификации.
В приведенных примерах вы доказываете факт владения закрытым ключом (на смартфоне, на аппаратном носителе или еще на чем-то), что и является фактором.
В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.
Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.
Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.
Физический токен или отпечаток пальца — надежно, но не скоро это будет у каждого.
Практически все новые телефоны всех классов имею SEP и считыватель отпечатков
Фактор владения байтами (приватный ключ) не больше фактора знания пароля. А тут предлагают для каждого сайта ставить по лишнему приложению только для авторизации.
Пароль это статическое значение. Подпись приватным ключом это уникальный идентификатор на каждый вызов
Сайты будут закладывать такую реализацию, которая и для них удобна и для пользователя безопасна.
FIDO2 удобнее и безопаснее
Я понял, что вы предлагаете хранить приватный ключ (которого можно сделать копию) в приложении на телефоне
Приватные ключи хранятся в SEP либо в худшем случае в keychain на системном уровне, для извлечения которых нужно минимум рутировать телефон не говоря о их расшифровке
какой смысл в стандартизации протокола?
Потому что аутентификация слишком критичный элемент безопасности интернета чтобы оставлять его разработчикам. Когда TLS/SSL выходил люди говорили тоже самое.
Я привел пример, когда вы можете видеть использование одной и той же технологии (push) при аутентификации. И там и там push. Но методы то совсем разные.
Это как если вам нужно использовать шифрование: вы можете использовать стандартный алгоритм AES, а можете взять какой-то алгоритм, который не стандартизован, но зато придуман вами и является на ваш взгляд более надежным.
В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.
Ну вот вы не видите, что происходит, а пока вы держите телефон, приложение отправляет на сервер приват24 информацию, что вы — аутентифицированный пользователь. Я предполагаю, что в этот момент общение между приложением и сервером примерно такое:
1. приложение сообщает серверу, что хочет аутентифицировать пользователя.
2. Сервер отправляет нонс
3. Приложение его подписывает закрытым ключом и возвращает ответ серверу.
4. Сервер проверяет подпись.
Фактор владения байтами (приватный ключ) не больше фактора знания пароля
Есть разные угрозы. От подсматривания, кейлоггеров или даже от утечки на стороне поставщика услуг мобильное приложение с закрытым ключом более предпочтительно, чем парольная аутентификация.
Говорить, что какой-то фактор больше или меньше другого, некорректно. Тем более, что даже в приведенном мной примере можно использовать PIN-код(аналог пароля) для доступа к закрытому ключу. А значит, что это уже двухфакторная аутентификация.
2. Врятли все так сложно. Скорее всего телефон по SSL отправляет «пользователь с ID сессии хочет зайти через браузер, ID сессии в браузере». И в принципе серверу нет причин не доверять, в своем же приложении он уже аутетифицировал пользователя, тоже самое можно и в браузере сделать.
Серверу есть причина никому не доверять как и клиенту есть причина никому не доверять. Интернет это дикий запад.
Наш стандарт дает возможность пользоваться доступной, легкой, фишинг безопасной аутентификацией которую будут поддерживать все члены этой экосистемы.
Как железные дороги покорили дикий запад, так и мы убьем фишинг.
Скачиваете банковский клиент на телефон и проходите аутентификацию…Кажется, начинаю понимать: имеется ввиду связь не через сети мобильного оператора, а обычный интернет, доступный через любой публичный вайфай. Действительно, тогда не нужен ни номер, ни активная сим-карта в аппарате. Более того, и сам телефон не нужен — достаточно любого компа, подключённого в интернет.
… Как видите нигде телефонный номер не был использован
В связи с оживленным интересом к протоколу, я за пару дней напишу статью, где я более технически разъясню все аспекты. На все что вы бы хотели видеть ответы пишите здесь *)
Возможно, вы не живете в РФ, но тут
Способ хранения как было сказано «Это не часть протокола», но должен быть, иначе не правильная реализация поставит крест на безопасности.
Стандарт нужно дорабатывать.
Стандарт не может диктовать требования к хранилищу аутентификаторов, это уже дело сертификации. В FIDO у нас есть:
- L1 — техническая сертификация + минимальный аудит безопасности
- L2/3/4 — L1 + пентестинг + аудит лабораториями + куча всего другого для прохождения FIPS1/140 etc
Так что пользуйтесь сертифицированными продуктами *)
Так что пользуйтесь сертифицированными продуктамиПравильные пароли и отсутствие ленности в вопросах безопасности делают не интересной, лично для меня, эту технологию. Т.е. использовать не планирую.
А вот вопросы безопасности и возможные утечки всё еще интересуют, но как я понимаю это надо смотреть в релизах соответствующих версий браузеров.
Пользователь через компьютер или ноутбук заходит на сайт example.ru и видит опцию «Войти с помощью телефона».
То есть сайт example.ru определяет, что пользователь может входить только через его мобильное приложение? И через USB-HID устройство войти нельзя или стандарт обязывает принимать любой "Аутентификатор"?
Нет, всё-таки есть тут что-то неправильное, неудобное… Ещё раз напоминаю — есть примеры, что в деле аутентификации можно обойтись вообще без телефона. Для меня они предпочтительнее: как ни крути, а телефон — это легальный шпион, постоянно носимый с собою.
Смотрите. Я смотрю на телефон как на еще один аутентификатор. Так же у меня есть железные аутентификаторы от компаний Yubico и Feitian. Так же у меня есть ноутбук со считывателем отпечатков и SGX.
Это как в песне: Аутентификаторы бывают разные, биометрические, мобильные, железные, встроенные, разныыыыеее *)
Я смотрю на телефон как на еще один аутентификатор.Допустим.
Но как быть если я захожу на сайт через свой телефон?
Захожу с телефона, и на телефон приходи авторизация?
Учитывая статистику прошлого года, тех кто сидит с телефона большую часть времени уже больше половины, и это очень актуальный вопрос.
Открываешь сайт, вводишь appleID с паролем.
на телефоне, подвязанному к этому appleID, высвечивается OTP ключ для продолжения процедуры входа на сайт
ну и письмо на icloud.com, что был вход.
я не говорю что это плохо. Это круто и красиво, менеджер паролей в облаках + вторая аутентификация. Просто это не «космос», это уже есть.
Новые стандарты для беспарольной аутентификации: как они работают