Ну справедливости ради, как раз таки в случае с мостом часто делается задел на будущее. Например, автомобильный мост через ж/д пути будет длиннее и иметь больше опор, чем нужно в действительности именно для того, чтобы потом между казалось бы лишними опорами проложить ещё несколько пар путей. И главное не факт, что настанет момент когда эти пути будут проложены, более того к тому времени могут построить новый мост ввиду износа старого с ещё большим заделом.
Только double.cloud развивается как самостоятельная единица, изначально ориентированная на западный рынок по такому же принципу как clickhouse.com и отделившийся задолго от разделения Яндекса. Но сам факт, что это изначально часть команды Yandex Cloud. Причём Double Cloud это та часть Yandex Cloud которая про Datalens чисто. И кодовая база у них была на yandex-team.ru.
Nebius это собственно урезанная часть Yandex Cloud, но с ориентиром на GPU Cloud и AI Cloud, результат разделения Яндекса и собственно это теперь уже бывшая Yandex N.V. (YNV), теперь уже Nebius N.V. Часть народа из Yandex Cloud перетекла в Nebius и кодовая база у них тоже до недавнего времени была на yandex-team.ru или во всяком случае в sync.
Т.к. double.cloud отделился раньше разделения Яндекса он не относится ни к Яндексу, ни к Nebius, но исторически это неофициально часть Yandex Cloud. Собственно как уже сказал по пути clickhouse.
А вот в отношении Yandex Cloud и Nebius, у первых рынок СНГ и та модель, что была, но они не могут выходить на Европу и США. А у Nebius собственно Европа и США, возможно Азия, но без СНГ и чисто AI/GPU Cloud.
Яндекс Толока (исходники и название) теперь Toloka (часть Nebius), но у Яндекса условно форк теперь Яндекс Задания.
Яндекс Такси тоже специфично поделился это Яндекс Такси и Avride (часть Nebius), пока Avride чисто про автопилоты (ввиду ограничений), но потенциально европейский YanGo (Такси и доставка) за ними же.
И естественно у Yandex Cloud нет упоминаний ни Double Cloud, ни Nebius, ни у тех нет явного упоминания Yandex Cloud, по понятным причинам. Зато потихоньку убирающиеся неявные указания что это так то всё одна компания была и инфраструктура была частично общая.
Так, что если нет упоминания про Nebius и их взаимосвязь в разделе О компании всех их, это ещё не значит что команды не были едиными в т.ч. неофициально на период разделения, который к слову ещё окончательно не завершен, юридически может быть это уже и самостоятельные единицы в разных юрисдикциях, однако соглашения по обмену кодовой базой ещё не завершены, временная лицензия на использование кода тоже пока действует, хоть и не долго.
Вот я тоже думаю, что либо в качестве исключения всё же будет просто история с передачей управления доменной зоной как с .su. Но даже если такой передачи между странами не будет, то просто скорее всего вся зона уйдет кому-нибудь по типу Verizon и т.д. т.е. домен просто поменяет статус с ccTLD в gTLD в рамках программы New gTLD и всё. Это проще и безболезненней чем закрывать целую зону, достаточно долго имеющую негласную тематическую ассоциацию с I/O.
Скорее Find My Device и может ещё определение землетрясений (Safetyhub), "история геолокации" сейчас хранится на устройстве и не передается без входящего push.
Удобнее не является эталонным значением, это всего лишь допущение точности значения. Можете считать пределы как и теорию относительности абстракциями для абстракций. Просто "удобно" не учитывать погрешности, которые в решении конкретной задачи не вносят критического веса в результат вычислений. По сути уменьшение точности результата вычислений для экономии ресурсов необходимых, для получения воспроизводимого достаточного результата, но не эталонного.
Так то часы это конкретная единица в конечном счёте завязанная на физические штуки. Иначе собственно с чего это вдруг GPS прямо завязанное на часы является физической штукой? В таком случае GPS такое же абстрактное понятие, как и часы. Как бы явное противоречие, если GPS физическая штука то и время такая же физическая штука, ведь без времени GPS не работает, а если время абстрактно, то и GPS абстрактно. Если конечно уходить совсем далеко в теорию относительности, то всё абстрактно... Только вот GPS конкретно привязана к земле и земному времени, что явно завязано на физические процессы связанные с землёй в конечном счёте период обращения земли вокруг солнца, своей оси и т.д.
Там всё очень очевидно и определено Google, Apple и Microsoft пришли к тому, что у каждой из этих компаний есть своё хранилище паролей Google Password Manager, Apple Keychain, Windows Hello. Которые суммарно покрывают большую часть пользовательских устройств.
Буквально у практически любого человека есть хотя бы один аккаунт у одной из этих компаний т.к. имеется хотя бы одно устройство из одной из трёх крупнейших экосистем.
Так вот пользователь когда создаёт первый ключ (будем говорить о Passkey) в первую очередь создаётся cross-platform (это буквально best practice), такой ключ не привязан к устройству пользователя и может быть синхронизирован и собственно говоря синхронизируется в хранилище. В зависимости от экосистемы устройства на котором создаётся ключ он будет либо в Google Password Manager, либо в Apple Keychain, либо в Windows Hello.
Т.е. основной ключ у него легко синхронизируется в рамках одной экосистемы, если нужно войти в устройстве из другой экосистемы тут как раз и будет отрабатывать caBLE с QR и связыванием устройств (браузер буквально запомнит инфу для повторного подключения уже без QR и будет в списке устройств предлагать связанное). Более того эта инфа сейчас хранится на устройстве и к ней имеет доступ не только Google Chrome, но и Windows Hello вполне будет видеть связанное устройство. Таким образом потеря устройства не становится такой большой проблемой, ключ можно восстановить из облака.
Далее после создания первого ключа на сайте опять таки по best practice сайт предложит сделать platform ключ (он не синхронизируется и привязан к устройству жёстко, из чипа не экспортируется). Так и будет описано, что для обеспечения более простого взаимодействия на устройстве. Такие ключи по сути рекомендуется пользователю иметь на основных устройствах. При входе с нового устройства с применением cross-platform ключа также будет предлагаться сделать platform ключ для этого устройства.
Сам Google при входе в его аккаунт с Android автоматически создаёт такой platform ключ в аккаунте.
Важно, что все эти ключи создаются и работают при включенной блокировке экрана, хотя бы с графическим кодом. Надёжность и сложность разблокировки устройства полностью за пользователем, если нужно соблюсти требования пользователь ставит либо сложный пин, либо биометрию. Всё дело в том, что разблокировка устройства происходит через безопасный чип, сама разблокировка по сути расшифровывает мастер ключ чипа.
А ещё вы можете добавить cross-platform ключ в виде юбика и подобных nfc/BLE/usb security key.
В основном при утере будет удаляться либо юбик, либо platform ключ (как раз отзыв устройства в вашем примере), ключ из экосистемы пользователь вряд ли будет удалять, скорее просто удаленно разлогинит устройство из экосистемы.
Если у пользователя есть по ключу в каждой из трёх экосистем, как таковой платформенные ключи особо и не нужны.
По сути нигде. Это решение связанное с продвижением Passkeys именно резидентных ключей с организацией дополнительно синхронизации в хранилищах ключей, всё для того, чтобы упростить жизнь пользователей. Минимизация проблем при утере устройства, когда синхронизируется ключ фактически не потерян и может быть восстановлен из облака. Так же и caBLE по сути помогает использовать ключи на устройствах из других экосистем с поддержкой связывания собственно говоря.
Собственно логика простая, если это обычный пользователь без каких-то доп требований и ограничений по типу air gapped инфраструктуры, то вот caBLE и Passkeys с интеграцией в хранилища ключей и синхронизации с облаками.
Если что-то специфичное, то уже обычные ключи по типу юбиков, которые можно отслеживать по серийникам и т.д. и т.п. Что глобально работает также, только транспорт usb/nfc/Bluetooth.
Да и в целом у всех у кого есть смартфон и ноутбук проблем с caBLE точно нет, для стационарников тоже постепенно пропадает т.к. на материнках всё чаще уже имеется Bluetooth модуль как собственно и TPM. Ну а интернет сейчас повсеместно, даже в банальном сценарии оплаты в магазине.
Тут вообще уже как бы современные тенденции к тому, чтобы у устройства был Bluetooth, TPM (или другой специализированный чип), ещё и чипы для машинного вычисления NPU. Чем дальше тем больше всего такого будет обязательным и это не плохо на самом деле.
Владелец сайта сам не знает каким методом через что там внутри отрабатывает, он видит только WebAuthn, который для него стандартный API, а вот платформа которая предоставляет это API и реализует уже по разному выглядит, разные опции даёт (по QR, по usb/nfc/BLE или вообще как-то проприетарно). Это вообще не известно владельцу сайта, потом это может быть целенаправленное требование как число символов в пароле и наличие спец символов. Ну если сайт ограничил на английском алфавите пароли, хоть как пользователь может плясать, кириллицу он не сможет использовать и собственно владельцам сайтов уже в данном случае заведомо всё-равно, а бывают ещё и законодательные требования, как внезапно пропали входы по OAuth в Яндексе со внешних сервисов.
Ну ладно, не хотим шнурок или не можем проводом - ну так все равно же Bluetooth используется - почему бы по нему всю нужную информацию не передать?
Я не проверял возможность использовать смартфон при ручном выборе аутентификации по Bluetooth, но caBLE форсируется из-за интеграции с платформой, те же связывания устройств, чтобы QR использовался только при первом входе с устройства, а дальше его можно было выбрать в меню и инициировать связь уже без QR через те же пуши.
Условно говоря отдана на аутсорс не владельцами сайта/приложения, а скорее владельцами платформы на которой этот сайт/приложение доступны и скорее даже не на аутсорс, а владельцы платформы сами предоставили данный сервис. Всё же это несколько иное, отношения к сайту ровно ни какого.
По USB, возможно это будет реализовано, возможно нет, однозначно связано с режимом работы и протоколом по USB, не просто так ведь есть выбор зарядка, передача файлов, midi, etc.
Всё же тебе юбики выполняю одну задачу, соответственно и протокол применяемый к usb порту будет так же единственным. Как и у флешек или камер.
На самом деле в теории по caBLE можно и юбики подключить, я на это собственно и указал, что гибридный аутентификатор это собственно приложение на смартфоне, которое как раз и устанавливает соединение из QR. В случае Android это будет Chrome или Play Services, однако за этим приложением стоит дальнейшее общение по hid с чипом.
Предположу, что изначально идея была в работе с QR без проводов, собственно caBLE это же Cloud Assisted BLE. Но общие концепции можно переложить как я указал на другие транспорты поменяв WebSocket на что-то ещё.
Это у них развесистая экосистема. Просто для одиночного сайта можно считать, что соответствующий сервер аутентификации - это часть сайта.
В том то и дело, что нет, это на данный момент два единственно известных релея для caBLE, придумывали caBLE в Google и сейчас это уже вторая версия.
Если вы используете соединение на смартфоне с сервисами Google или с Google Chrome, релеем будет cable.ua5v.com, если вы пользуетесь устройством Apple релеем будет cable.auth.com.
Ещё раз повторюсь, что конечный релей выбирает гибридный аутентификатор т.е. устройство, которое отсканировало QR, оно же эту информацию предоставит клиенту (десктоп к примеру) через зашифрованный BLE Advert.
Т.е. если вы отсканируйте на iPhone отображенный в Google Chrome QR, то общение будет через cable.auth.com.
Всё по тому, что через данные релеи можно инициировать соединение с привязанным устройством без QR, что по сути является запросом на специальный эндпоинт на релее: cable.auth.com/cable/contact/...
В данном случае релей отправит push уведомление на iPhone с данными для подключения. Собственно приложение реализующее гибридный аутентификатор получит данное уведомление и запустит BLE Advert.
Т.е. известно на данный момент о двух релеях, которые по сути управляются крупными производителями. На Android устройствах без Google Play Services, очевидно должено быть реализовано своё приложение, которое выступит гибридным аутентификатором и свой релей т.е. потенциально это Microsoft, если решат вновь взяться за мобильные устройства и пожалуй Huawei, ну может кто-нибудь у нас по импортозамещению такое сделает. Ну или на крайний случай Энтерпрайз для поддержки caBLE через своё приложение в своей закрытой сети со своим релеем.
Опять таки к сайту релеи не имеют никакого отношения и вообще глобально, что приложения, что сайты даже не в курсе того, что есть какие-то посредники, они видят чисто SDK, который за собой скрывает общение на прямую по ctap на hid, или общение через туннель, в конечном счёте превращающиеся в ctap по hid.
И всё же QR это хендшейк точнее часть хендшейка, в нем хранится публичный ключ для ECDH, shared secret (16 байт), число известных стандартизированных тоннелей (24 байта), доп флаги (дата, поддержка state assist) и хинт операции (создание ключа или подпись).
BLE Advert зашифрованная информация по выбранному хосту туннелирования, коду соединения и т.д.
По сути весь CTAP Cable можно реализовать и локально заменив Websocket общением по usb кабелю, чего сейчас нет, темнее как бы намекает.
В конечном счёте этим самым гибридным соединением управляет клиент (пусть и на стороне аутентификатора) с самим же чипом общение идёт по ctap на hid. У юбиков ну никак нет интернета.
Само наличие туннеля в гибриде темнеменее я не могу отнести к "общается с сайтом" т.к. туннель тут третья сторона, которая просто предоставила релей (сообщения отправляемые в туннель шифруются), более того туннель принадлежит реализующим данный гибридный аутентификатор сторонам.
Т.е. у Google (Chrome, Android, Play Services) это cable.ua5v.com и им владеет Google. У Apple это cable.auth.com.
В любом случае caBLE потенциально может использовать любой другой альтернативный канал кроме Интернета, за исключением Bluetooth.
Тут именно суть в том, гибридный аутентификатор, способный работать с QR является посредником между аутентификатором и клиентом. И в целом если клиент и гибридный аутентификатор умеют ходить не через сеть, а как-то ещё, сохраняя общий принцип установки туннеля по QR, то собственно им ничего не мешает это сделать другое дело это выход из текущего стандарта.
Ну это не совсем так, на сайт ничего не лезет от слова совсем, сайт общается через WebAuthn с хостом (браузер/sdk для нативных приложений) и обменивается только запросами регистрации или подписи, получая только ответ, браузер/sdk общаются уже по ctap с аутентификатором, который либо чип на этом же устройстве, либо подключенный внешний как-либо, если используется QR, то там общение происходит по Bluetooth для того, чтобы был фактор присутствия, если компьютер и смартфон могут соединиться по Bluetooth или nfc или usb мы уверены, что они рядом друг с другом. Это борьба с тем, что сфоткал QR, отправил куда-то и оттуда пытаешься подписать.
В теории в схеме с QR можно использовать кроме Bluetooth ещё и usb/nfc, но они не применяются. Возможно (надо посмотреть исходники хромиума) в схеме с QR устройства могут соединиться в рамках одной сети (Wi-Fi), тогда в схеме QR не нужны usb/nfc. Это на самом деле потенциальный feature request. Сам QR это по сути хендшейк на соединение по ctap.
Точно есть одно место где хромиум ходит по сети, это чтобы на связанное устройство отправить пуш уведомление с теми же настройками, что и в QR, а далее вновь Bluetooth.
Но хендшейк тут и все общение ctap вообще не затрагивает сайт.
Используйте смартфон от Apple, Google или Microsoft (это уже вряд ли) там уже имеется необходимый чип и вероятнее даже уже Passkeys доступны или в скором времени станут доступны (у Google и Apple уже).
Согласен, по сути весь Passkeys это плюс/минус тоже что происходит и с банковскими картами. При том же посещении банка когда просят поднести или вставить в терминал любую карту банка и ввести пин код.
Но токены по типу юбиков это всё же чуть другой уровень, это как те же корпоративные карты доступа (у сотрудников банка к примеру) там требования чуть повыше чем к банковским картам клиентов.
Ну как сказать, не явно завалили - в смартфонах уже повсеместно стоят спец. чипы. Всякие Google Titan (чип) у Apple свой есть, TPM тот же.
А вот устройства (те же чипы но с единственной задачей) по типу юбиков и т.д. это отдельный класс там есть и отдельные сертификации по типу fips для специфичных условий и применения в тех же госах. По сути они такие дорогие из-за своего класса и лицензирования. В основном в этих контроллерах дорогое это экранирования и прочие вещи с усложнением создания копии (речь про данные конечно же).
Если totp, то затравка для него не хешируется и при утечке с сервера базы затравок сразу вскрываются все аккаунты.
В смысле? Т.е. вы храните секретные ключи своих клиентов как plaintext? Вроде бы все понятно, что секреты (пароли, API токены и т.д. и т.п.) нужно хранить заранее подготавливая - пароли хешируем, секреты которые нужно использовать, а не только проверять шифруем. Да даже PII нужно шифровать уже как бы...
То есть, всё-таки totp.
Очевидно, что ваш собеседник про FIDO2 в частности Passkeys (FIDO2 Discoverable Credentials).
Если по одному на каждый аккаунт, то у меня в базе кипасса пара сотен записей. Это мне с чемоданом токенов ходить прикажете?
Подход с FIDO2 который сейчас формируется это делаешь ключ в любом переносимом/платформонезависимом хранилище (1-2 хранилища) это может быть Yubikey, Рутокен + любой кейчейн которому доверяешь Google Passwords, Apple Keychain, Microsoft Hello, KeePass, etc... И несколько ключей на устройстве (платформозависимые) для быстроты авторизации (это уже опционально).
И при необходимости расплатиться в магазе по qr-колу перерыть весь чемодан в поисках токена от банка.
QR будет, если вы не будите иметь рядом usb/nfc или платформозависимые (на устройстве) ключ и то его нужно только отсканировать и ввести код разблокировки. Искать в чемодане не нужно он сами найдутся т.к. инфа для поиска user handle на ключах уже хранится (это касается FIDO2 Discoverable Credentials, они же резидентные).
Ну, и см выше про утечки - они в этом случае на порядки опаснее утечек баз паролей.
Не правда, FIDO2 на стороне сервера позволяет хранить только публичный ключ и максимум ряд технический параметров ключа (включая число использований). Утечка публичного ключа вообще не страшна на то он и публичный. Здесь другие векторы атаки нужны: нужно либо своровать токен, но он защищён пином и имеет лимит на число неверных вводов, либо ломать устройство, тоже есть защиты.
По сути FIDO2 и конкретно Passkeys это аналог плюс/минус того, что люди итак носят с собой (банковские карточки), только пин там не лимитируется в длине и нет cvc/cvv. (Вспоминаем аутентификацию в банке - пришли в банк за услугой, вас попросили приложить к терминалу любую карточку банка и ввести пин).
Именно поэтому железные токены используют именно как второй фактор, а не как основной.
Ну для начала Passkeys сам по себе это уже мультифактор - владение (устройством/юбиком), знание (пин), присутствие (взаимодействие, расстояние между устройствами общающимися по ctap и таймауты).
На GitHub можно использовать как основной способ входа, на Google аналогично, на Mos.ru, даже на Яндексе. Относительно Google они вообще своих сотрудников ещё в далёкие года переводили на юбики.
В случае потери токены у вас если вы позаботились будет резервный способ (другой токен), если вы входили через токен в облачном кейчейне, разлогиниваете потерянное устройство в сервисе с ключами, если потеряли устройство с платформозависимые ключом (а это и юбики в т.ч.) заходите с использованием дополнительного ключа на другом устройстве к примеру (с компьютера, если потерян смартфон) и в аккаунте удаляете эти ключи, да тут нужно в каждом сервисе лазить удалять, но запас времени есть т.к. ключи всё-равно под пином. В отличии от утекшего пароля, который прям везде один это не отличается по смене паролей ничем кроме того, что утекший пароль не защищён ещё дополнительным пином и его можно использовать сразу везде (всё же для каждого сайта будет новый FIDO ключ).
Ну справедливости ради, как раз таки в случае с мостом часто делается задел на будущее. Например, автомобильный мост через ж/д пути будет длиннее и иметь больше опор, чем нужно в действительности именно для того, чтобы потом между казалось бы лишними опорами проложить ещё несколько пар путей. И главное не факт, что настанет момент когда эти пути будут проложены, более того к тому времени могут построить новый мост ввиду износа старого с ещё большим заделом.
Вполне, он уже может быть там, просто не афишируя, под такой же трактовкой "консультация" по проекту.
Если, что Yandex Cloud это изначально не только собственно yandex.cloud, но ещё и double.cloud и nebius.com.
Только double.cloud развивается как самостоятельная единица, изначально ориентированная на западный рынок по такому же принципу как clickhouse.com и отделившийся задолго от разделения Яндекса. Но сам факт, что это изначально часть команды Yandex Cloud. Причём Double Cloud это та часть Yandex Cloud которая про Datalens чисто. И кодовая база у них была на yandex-team.ru.
Nebius это собственно урезанная часть Yandex Cloud, но с ориентиром на GPU Cloud и AI Cloud, результат разделения Яндекса и собственно это теперь уже бывшая Yandex N.V. (YNV), теперь уже Nebius N.V. Часть народа из Yandex Cloud перетекла в Nebius и кодовая база у них тоже до недавнего времени была на yandex-team.ru или во всяком случае в sync.
Т.к. double.cloud отделился раньше разделения Яндекса он не относится ни к Яндексу, ни к Nebius, но исторически это неофициально часть Yandex Cloud. Собственно как уже сказал по пути clickhouse.
А вот в отношении Yandex Cloud и Nebius, у первых рынок СНГ и та модель, что была, но они не могут выходить на Европу и США. А у Nebius собственно Европа и США, возможно Азия, но без СНГ и чисто AI/GPU Cloud.
Яндекс Толока (исходники и название) теперь Toloka (часть Nebius), но у Яндекса условно форк теперь Яндекс Задания.
Яндекс Такси тоже специфично поделился это Яндекс Такси и Avride (часть Nebius), пока Avride чисто про автопилоты (ввиду ограничений), но потенциально европейский YanGo (Такси и доставка) за ними же.
И естественно у Yandex Cloud нет упоминаний ни Double Cloud, ни Nebius, ни у тех нет явного упоминания Yandex Cloud, по понятным причинам. Зато потихоньку убирающиеся неявные указания что это так то всё одна компания была и инфраструктура была частично общая.
Так, что если нет упоминания про Nebius и их взаимосвязь в разделе О компании всех их, это ещё не значит что команды не были едиными в т.ч. неофициально на период разделения, который к слову ещё окончательно не завершен, юридически может быть это уже и самостоятельные единицы в разных юрисдикциях, однако соглашения по обмену кодовой базой ещё не завершены, временная лицензия на использование кода тоже пока действует, хоть и не долго.
Вот я тоже думаю, что либо в качестве исключения всё же будет просто история с передачей управления доменной зоной как с .su. Но даже если такой передачи между странами не будет, то просто скорее всего вся зона уйдет кому-нибудь по типу Verizon и т.д. т.е. домен просто поменяет статус с ccTLD в gTLD в рамках программы New gTLD и всё. Это проще и безболезненней чем закрывать целую зону, достаточно долго имеющую негласную тематическую ассоциацию с I/O.
Скорее Find My Device и может ещё определение землетрясений (Safetyhub), "история геолокации" сейчас хранится на устройстве и не передается без входящего push.
Ну глобально и в изначальной Толоке пока ещё не было раздела Яндекса, цены в основном такие же были.
Я просто указал, что толока теперь в портфеле у Nebius, а новая локальная это Яндекс Задания.
Toloka при разделении ушла в пользу Nebius, МКАО Яндекс запустил локализованную версию как Яндекс Задания
Удобнее не является эталонным значением, это всего лишь допущение точности значения. Можете считать пределы как и теорию относительности абстракциями для абстракций. Просто "удобно" не учитывать погрешности, которые в решении конкретной задачи не вносят критического веса в результат вычислений. По сути уменьшение точности результата вычислений для экономии ресурсов необходимых, для получения воспроизводимого достаточного результата, но не эталонного.
Так то часы это конкретная единица в конечном счёте завязанная на физические штуки. Иначе собственно с чего это вдруг GPS прямо завязанное на часы является физической штукой? В таком случае GPS такое же абстрактное понятие, как и часы. Как бы явное противоречие, если GPS физическая штука то и время такая же физическая штука, ведь без времени GPS не работает, а если время абстрактно, то и GPS абстрактно. Если конечно уходить совсем далеко в теорию относительности, то всё абстрактно... Только вот GPS конкретно привязана к земле и земному времени, что явно завязано на физические процессы связанные с землёй в конечном счёте период обращения земли вокруг солнца, своей оси и т.д.
Там всё очень очевидно и определено Google, Apple и Microsoft пришли к тому, что у каждой из этих компаний есть своё хранилище паролей Google Password Manager, Apple Keychain, Windows Hello. Которые суммарно покрывают большую часть пользовательских устройств.
Буквально у практически любого человека есть хотя бы один аккаунт у одной из этих компаний т.к. имеется хотя бы одно устройство из одной из трёх крупнейших экосистем.
Так вот пользователь когда создаёт первый ключ (будем говорить о Passkey) в первую очередь создаётся cross-platform (это буквально best practice), такой ключ не привязан к устройству пользователя и может быть синхронизирован и собственно говоря синхронизируется в хранилище. В зависимости от экосистемы устройства на котором создаётся ключ он будет либо в Google Password Manager, либо в Apple Keychain, либо в Windows Hello.
Т.е. основной ключ у него легко синхронизируется в рамках одной экосистемы, если нужно войти в устройстве из другой экосистемы тут как раз и будет отрабатывать caBLE с QR и связыванием устройств (браузер буквально запомнит инфу для повторного подключения уже без QR и будет в списке устройств предлагать связанное). Более того эта инфа сейчас хранится на устройстве и к ней имеет доступ не только Google Chrome, но и Windows Hello вполне будет видеть связанное устройство. Таким образом потеря устройства не становится такой большой проблемой, ключ можно восстановить из облака.
Далее после создания первого ключа на сайте опять таки по best practice сайт предложит сделать platform ключ (он не синхронизируется и привязан к устройству жёстко, из чипа не экспортируется). Так и будет описано, что для обеспечения более простого взаимодействия на устройстве. Такие ключи по сути рекомендуется пользователю иметь на основных устройствах. При входе с нового устройства с применением cross-platform ключа также будет предлагаться сделать platform ключ для этого устройства.
Сам Google при входе в его аккаунт с Android автоматически создаёт такой platform ключ в аккаунте.
Важно, что все эти ключи создаются и работают при включенной блокировке экрана, хотя бы с графическим кодом. Надёжность и сложность разблокировки устройства полностью за пользователем, если нужно соблюсти требования пользователь ставит либо сложный пин, либо биометрию. Всё дело в том, что разблокировка устройства происходит через безопасный чип, сама разблокировка по сути расшифровывает мастер ключ чипа.
А ещё вы можете добавить cross-platform ключ в виде юбика и подобных nfc/BLE/usb security key.
В основном при утере будет удаляться либо юбик, либо platform ключ (как раз отзыв устройства в вашем примере), ключ из экосистемы пользователь вряд ли будет удалять, скорее просто удаленно разлогинит устройство из экосистемы.
Если у пользователя есть по ключу в каждой из трёх экосистем, как таковой платформенные ключи особо и не нужны.
По сути нигде. Это решение связанное с продвижением Passkeys именно резидентных ключей с организацией дополнительно синхронизации в хранилищах ключей, всё для того, чтобы упростить жизнь пользователей. Минимизация проблем при утере устройства, когда синхронизируется ключ фактически не потерян и может быть восстановлен из облака. Так же и caBLE по сути помогает использовать ключи на устройствах из других экосистем с поддержкой связывания собственно говоря.
Собственно логика простая, если это обычный пользователь без каких-то доп требований и ограничений по типу air gapped инфраструктуры, то вот caBLE и Passkeys с интеграцией в хранилища ключей и синхронизации с облаками.
Если что-то специфичное, то уже обычные ключи по типу юбиков, которые можно отслеживать по серийникам и т.д. и т.п. Что глобально работает также, только транспорт usb/nfc/Bluetooth.
Да и в целом у всех у кого есть смартфон и ноутбук проблем с caBLE точно нет, для стационарников тоже постепенно пропадает т.к. на материнках всё чаще уже имеется Bluetooth модуль как собственно и TPM. Ну а интернет сейчас повсеместно, даже в банальном сценарии оплаты в магазине.
Тут вообще уже как бы современные тенденции к тому, чтобы у устройства был Bluetooth, TPM (или другой специализированный чип), ещё и чипы для машинного вычисления NPU. Чем дальше тем больше всего такого будет обязательным и это не плохо на самом деле.
Владелец сайта сам не знает каким методом через что там внутри отрабатывает, он видит только WebAuthn, который для него стандартный API, а вот платформа которая предоставляет это API и реализует уже по разному выглядит, разные опции даёт (по QR, по usb/nfc/BLE или вообще как-то проприетарно). Это вообще не известно владельцу сайта, потом это может быть целенаправленное требование как число символов в пароле и наличие спец символов. Ну если сайт ограничил на английском алфавите пароли, хоть как пользователь может плясать, кириллицу он не сможет использовать и собственно владельцам сайтов уже в данном случае заведомо всё-равно, а бывают ещё и законодательные требования, как внезапно пропали входы по OAuth в Яндексе со внешних сервисов.
Я не проверял возможность использовать смартфон при ручном выборе аутентификации по Bluetooth, но caBLE форсируется из-за интеграции с платформой, те же связывания устройств, чтобы QR использовался только при первом входе с устройства, а дальше его можно было выбрать в меню и инициировать связь уже без QR через те же пуши.
Условно говоря отдана на аутсорс не владельцами сайта/приложения, а скорее владельцами платформы на которой этот сайт/приложение доступны и скорее даже не на аутсорс, а владельцы платформы сами предоставили данный сервис. Всё же это несколько иное, отношения к сайту ровно ни какого.
По USB, возможно это будет реализовано, возможно нет, однозначно связано с режимом работы и протоколом по USB, не просто так ведь есть выбор зарядка, передача файлов, midi, etc.
Всё же тебе юбики выполняю одну задачу, соответственно и протокол применяемый к usb порту будет так же единственным. Как и у флешек или камер.
На самом деле в теории по caBLE можно и юбики подключить, я на это собственно и указал, что гибридный аутентификатор это собственно приложение на смартфоне, которое как раз и устанавливает соединение из QR. В случае Android это будет Chrome или Play Services, однако за этим приложением стоит дальнейшее общение по hid с чипом.
Предположу, что изначально идея была в работе с QR без проводов, собственно caBLE это же Cloud Assisted BLE. Но общие концепции можно переложить как я указал на другие транспорты поменяв WebSocket на что-то ещё.
В том то и дело, что нет, это на данный момент два единственно известных релея для caBLE, придумывали caBLE в Google и сейчас это уже вторая версия.
Если вы используете соединение на смартфоне с сервисами Google или с Google Chrome, релеем будет cable.ua5v.com, если вы пользуетесь устройством Apple релеем будет cable.auth.com.
Ещё раз повторюсь, что конечный релей выбирает гибридный аутентификатор т.е. устройство, которое отсканировало QR, оно же эту информацию предоставит клиенту (десктоп к примеру) через зашифрованный BLE Advert.
Т.е. если вы отсканируйте на iPhone отображенный в Google Chrome QR, то общение будет через cable.auth.com.
Всё по тому, что через данные релеи можно инициировать соединение с привязанным устройством без QR, что по сути является запросом на специальный эндпоинт на релее: cable.auth.com/cable/contact/...
В данном случае релей отправит push уведомление на iPhone с данными для подключения. Собственно приложение реализующее гибридный аутентификатор получит данное уведомление и запустит BLE Advert.
Т.е. известно на данный момент о двух релеях, которые по сути управляются крупными производителями. На Android устройствах без Google Play Services, очевидно должено быть реализовано своё приложение, которое выступит гибридным аутентификатором и свой релей т.е. потенциально это Microsoft, если решат вновь взяться за мобильные устройства и пожалуй Huawei, ну может кто-нибудь у нас по импортозамещению такое сделает. Ну или на крайний случай Энтерпрайз для поддержки caBLE через своё приложение в своей закрытой сети со своим релеем.
Опять таки к сайту релеи не имеют никакого отношения и вообще глобально, что приложения, что сайты даже не в курсе того, что есть какие-то посредники, они видят чисто SDK, который за собой скрывает общение на прямую по ctap на hid, или общение через туннель, в конечном счёте превращающиеся в ctap по hid.
И всё же QR это хендшейк точнее часть хендшейка, в нем хранится публичный ключ для ECDH, shared secret (16 байт), число известных стандартизированных тоннелей (24 байта), доп флаги (дата, поддержка state assist) и хинт операции (создание ключа или подпись).
BLE Advert зашифрованная информация по выбранному хосту туннелирования, коду соединения и т.д.
По сути весь CTAP Cable можно реализовать и локально заменив Websocket общением по usb кабелю, чего сейчас нет, темнее как бы намекает.
В конечном счёте этим самым гибридным соединением управляет клиент (пусть и на стороне аутентификатора) с самим же чипом общение идёт по ctap на hid. У юбиков ну никак нет интернета.
Само наличие туннеля в гибриде темнеменее я не могу отнести к "общается с сайтом" т.к. туннель тут третья сторона, которая просто предоставила релей (сообщения отправляемые в туннель шифруются), более того туннель принадлежит реализующим данный гибридный аутентификатор сторонам.
Т.е. у Google (Chrome, Android, Play Services) это cable.ua5v.com и им владеет Google. У Apple это cable.auth.com.
В любом случае caBLE потенциально может использовать любой другой альтернативный канал кроме Интернета, за исключением Bluetooth.
Тут именно суть в том, гибридный аутентификатор, способный работать с QR является посредником между аутентификатором и клиентом. И в целом если клиент и гибридный аутентификатор умеют ходить не через сеть, а как-то ещё, сохраняя общий принцип установки туннеля по QR, то собственно им ничего не мешает это сделать другое дело это выход из текущего стандарта.
Ну это не совсем так, на сайт ничего не лезет от слова совсем, сайт общается через WebAuthn с хостом (браузер/sdk для нативных приложений) и обменивается только запросами регистрации или подписи, получая только ответ, браузер/sdk общаются уже по ctap с аутентификатором, который либо чип на этом же устройстве, либо подключенный внешний как-либо, если используется QR, то там общение происходит по Bluetooth для того, чтобы был фактор присутствия, если компьютер и смартфон могут соединиться по Bluetooth или nfc или usb мы уверены, что они рядом друг с другом. Это борьба с тем, что сфоткал QR, отправил куда-то и оттуда пытаешься подписать.
В теории в схеме с QR можно использовать кроме Bluetooth ещё и usb/nfc, но они не применяются. Возможно (надо посмотреть исходники хромиума) в схеме с QR устройства могут соединиться в рамках одной сети (Wi-Fi), тогда в схеме QR не нужны usb/nfc. Это на самом деле потенциальный feature request. Сам QR это по сути хендшейк на соединение по ctap.
Точно есть одно место где хромиум ходит по сети, это чтобы на связанное устройство отправить пуш уведомление с теми же настройками, что и в QR, а далее вновь Bluetooth.
Но хендшейк тут и все общение ctap вообще не затрагивает сайт.
Используйте смартфон от Apple, Google или Microsoft (это уже вряд ли) там уже имеется необходимый чип и вероятнее даже уже Passkeys доступны или в скором времени станут доступны (у Google и Apple уже).
Согласен, по сути весь Passkeys это плюс/минус тоже что происходит и с банковскими картами. При том же посещении банка когда просят поднести или вставить в терминал любую карту банка и ввести пин код.
Но токены по типу юбиков это всё же чуть другой уровень, это как те же корпоративные карты доступа (у сотрудников банка к примеру) там требования чуть повыше чем к банковским картам клиентов.
Ну как сказать, не явно завалили - в смартфонах уже повсеместно стоят спец. чипы. Всякие Google Titan (чип) у Apple свой есть, TPM тот же.
А вот устройства (те же чипы но с единственной задачей) по типу юбиков и т.д. это отдельный класс там есть и отдельные сертификации по типу fips для специфичных условий и применения в тех же госах. По сути они такие дорогие из-за своего класса и лицензирования. В основном в этих контроллерах дорогое это экранирования и прочие вещи с усложнением создания копии (речь про данные конечно же).
В смысле? Т.е. вы храните секретные ключи своих клиентов как plaintext? Вроде бы все понятно, что секреты (пароли, API токены и т.д. и т.п.) нужно хранить заранее подготавливая - пароли хешируем, секреты которые нужно использовать, а не только проверять шифруем. Да даже PII нужно шифровать уже как бы...
Очевидно, что ваш собеседник про FIDO2 в частности Passkeys (FIDO2 Discoverable Credentials).
Подход с FIDO2 который сейчас формируется это делаешь ключ в любом переносимом/платформонезависимом хранилище (1-2 хранилища) это может быть Yubikey, Рутокен + любой кейчейн которому доверяешь Google Passwords, Apple Keychain, Microsoft Hello, KeePass, etc... И несколько ключей на устройстве (платформозависимые) для быстроты авторизации (это уже опционально).
QR будет, если вы не будите иметь рядом usb/nfc или платформозависимые (на устройстве) ключ и то его нужно только отсканировать и ввести код разблокировки. Искать в чемодане не нужно он сами найдутся т.к. инфа для поиска user handle на ключах уже хранится (это касается FIDO2 Discoverable Credentials, они же резидентные).
Не правда, FIDO2 на стороне сервера позволяет хранить только публичный ключ и максимум ряд технический параметров ключа (включая число использований). Утечка публичного ключа вообще не страшна на то он и публичный. Здесь другие векторы атаки нужны: нужно либо своровать токен, но он защищён пином и имеет лимит на число неверных вводов, либо ломать устройство, тоже есть защиты.
По сути FIDO2 и конкретно Passkeys это аналог плюс/минус того, что люди итак носят с собой (банковские карточки), только пин там не лимитируется в длине и нет cvc/cvv. (Вспоминаем аутентификацию в банке - пришли в банк за услугой, вас попросили приложить к терминалу любую карточку банка и ввести пин).
Ну для начала Passkeys сам по себе это уже мультифактор - владение (устройством/юбиком), знание (пин), присутствие (взаимодействие, расстояние между устройствами общающимися по ctap и таймауты).
На GitHub можно использовать как основной способ входа, на Google аналогично, на Mos.ru, даже на Яндексе. Относительно Google они вообще своих сотрудников ещё в далёкие года переводили на юбики.
В случае потери токены у вас если вы позаботились будет резервный способ (другой токен), если вы входили через токен в облачном кейчейне, разлогиниваете потерянное устройство в сервисе с ключами, если потеряли устройство с платформозависимые ключом (а это и юбики в т.ч.) заходите с использованием дополнительного ключа на другом устройстве к примеру (с компьютера, если потерян смартфон) и в аккаунте удаляете эти ключи, да тут нужно в каждом сервисе лазить удалять, но запас времени есть т.к. ключи всё-равно под пином. В отличии от утекшего пароля, который прям везде один это не отличается по смене паролей ничем кроме того, что утекший пароль не защищён ещё дополнительным пином и его можно использовать сразу везде (всё же для каждого сайта будет новый FIDO ключ).
Ну и Passkeys не подвержены фишингу.
Проблемы с ними были