Там всё очень очевидно и определено 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 ключ).
Ну почему же висит на ДГУ, уже как бы вновь от сети питается. За время пока Nebius AI ещё были просто Nebius, предоставляли мощности израильского дата-центра Nebius Israel и ориентировались на продажу облачной платформы по партнёрке, пока сделку по продаже доводили до фактического заключения вопросы по Финскому ДЦ урегулировались. Собственно Финский ДЦ теперь основной в Nebius AI, там же и парк обновили и статус Nvidia Preferred Partner получили.
Так ок, у нас есть DEK (симметричный), есть KEK (симметричный) по KDF, мы зашифровали клиентский приватный ключ (асимметричный) с помощью KEK (симметричный) по PBKDF2 (пароль знает только пользователь) допустим... Но что с нашим приватным ключом (асимметричный)? Он так же в открытую лежит на статическом хостинге? Или он тоже зашифрован, но данные расшифровки лежат рядом?
В этой схеме просто теряется смысл, по сути любой клиент имеет у себя в наличии сразу два приватных ключа... И вектор атаки очевидно - кража зашифрованного клиентского ключа + пароля для его расшифровки (соц. инженерия, фишинг, зловредные расширения), а серверный приватный ключ уже есть.
Тут без динамической части ну никак не обойтись в принципе, кто-то должен выступать второй стороной ответственной за ключ и хранящей его в тайне.
class может наследовать только классы, прототипом же может выступать любой объект
Вот тут я поправлю, класс может наследовать не только классы, но и функции.
Дело в том, что class это конструкция, которая по факту выполняет роль синтаксического сахара. Внутри это функция с прототипом равным содержимому класса. Вот например:
class User {
constructor(name, age) {
this.name = name;
this.age = age;
}
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
}
Если переписать без конструкции class вы получите этого:
function User(name, age) {
this.name = name;
this.age = age;
}
User.prototype = {
constructor: User,
sayHello() {
console.log(`Hello, my name is ${this.name}!`);
}
};
Если проверить тип класса из первого примера вы увидите, что результатом будет function.
По этому фактически классы (функции) наследуют функции.
Вообще давайте будем откровенны TOTP (RFC 6238 - май 2011) само по себе является расширением HOTP (RFC 4226 - декабрь 2005), которое просто заменяет инкрементируемый счётчик на временные интервалы (тот же счётчик, только автоматически инкрементируемый в соответствии с временем).
Сама суть HOTP/TOTP в том, что мы просто на просто хешируем счетчик с применением секрета, причём да изначально речь ведётся относительно HMAC-SHA1 и базово библиотеки/приложения HOTP/TOTP реализуют именно его (ну может +SHA256, если повезёт), однако допустимо использование HMAC-SHA256/HMAC-SHA512 да в целом любых HMAC-* хоть HMAC-SHA3-256. Т.е. уже один TOTP другому TOTP рознь как минимум из-за того, что можно менять алгоритм хеширования при сохранении общих принципов.
Далее у нас во всей этой теме с генерацией одноразового кода присутствует секрет, а им нужно обменяться! В простом случае этот секрет просто закодирован в base64 в uri в QR коде. А что если можно поделиться секретом более безопасно, даже явно не раскрывая секрета? Например, можно использовать ECDH с эфемерными ключами - всего две временные пары ключей, в открытую передаются только открытые части, но по результату у обеих сторон есть секрет.
А ещё можно сам одноразовый код отправлять, либо как уже упомянуто по клику на PUSH уведомление (на соответствующую сессионную ссылку из метаданных пуша) или эту ссылку можно ещё показать пользователю в виде QR кода (кстати, а вот и подход Яндекса).
А ещё самое банальное при всей совместимости и базовой реализации - не все приложения базово поддерживающие TOTP умеют в отличные от 6 значений коды, или даже в буквенные коды. (Ладно буквенные коды будем считать расширением, но возможность генерить коды более 6 знаков заложена ещё в HOTP, главное влезть динамическим окном в размерность хеша).
Так вот это к чему я, своё приложение это возможность поменять алгоритм хеширования (даже на экзотический) и/или поменять/обезопасить обмен секретом, а может даже облегчить жизнь пользователю, самостоятельно отправляя одноразовый код на сессионную ссылку из QR. И в определённых случаях это имеет достаточный смысл (сделать явно не как у всех - HMAC-SHA1/256 + QR с секретом).
А на счёт Whatsapp, Telegram - там OTP, но не TOTP/HOTP. У Google Messenger кстати тоже QR код с временным одноразовым значением, но он не для авторизации в аккаунте, а для пеиринга устройств во внутреннем pubsub.
Кстати на счёт Google, да TOTP на доп. факторе у них вполне стандартный, но Google точно так же как Яндекс экспериментирует с собственными транспортами для уже Passkeys (раньше Secure key). TOTP в данном случае уже не так интересен, особенно когда есть по свежее и по интереснее подход полностью на ключах.
А вообще конечно с развитием FIDO/WebAuthn и формированием Passkeys вот этот TOTP может стать просто на просто резервным способом (как одноразовые коды на бумажке) на случай потери доступа к материалам ключей (хотя они ведь будут синхронизироваться).
Просто интересно, если вам вдруг скажут, что ваши слова были неуместны, вы тоже будете обращаться к гражданскому кодексу?
Ну скажут и скажут, что толку слова уже произнесены, возможно в следующий раз такой ситуации не случится.
Тогда к чему этот разговор про пользовательское соглашение? Речь об эмоциональном восприятии программы, естественно, здесь никто никому ничего не обязан юридически.
В этом и суть мы говорим о программе/сервисе предоставляемом на конкретных условиях, условия заранее оглашены, другое дело на сколько человек в них вдавался. Далее эмоциональное тон программы формируется под конкретную аудиторию, а точнее часть этой аудитории (если хотите "среднее по больнице"), если этот тон не меняется в программе, значит всё хорошо (эмоциональное восприятие соответствует заложенному ожиданию) и всё работает как ожидают разработчики/компания владелец. То, что каждый уже по разному может воспринять тон и это вызовет какую-то не ожидаемую разработчиками эмоциональную реакцию уж извините, но это как с багами да и в целом идеалами - всем угодить не возможно т.к. как минимум все возможные случаи предусмотреть просто не выйдет.
А дальше говорил про нейтральный язык. И нет, нейтральное обращение обидеть не может. Просто по определению: оно нейтральное.
Какое бы нейтральное общение не было, но оно тоже может обидеть, мало говорить сухо/нейтрально без эмоциональной окраски, нужно ещё выбирать формулировки в целом учитывать контекст. Просто банально пример такой: Вот придёт к вам абсолютно нейтральная бумажка об отъеме земли в пользу государства с целью дальнейшей передачи, например РЖД для строительства новой очень важной федеральной магистрали, я сомневаюсь, что она вызовет у вас исключительно радостные эмоции или вообще не вызовет никаких.
Если во всяких мотивирующих лозунгах (в голове крутится "твори, выдумывай, пробуй!") такое обращение выглядит вполне уместным, то при продаже – вряд ли.
Но ведь это же "твори, выдумывай, пробуй!" может быть и при продаже, даже не то что в голове крутиться, а именно так и продаваться.
В общем, есть роли и есть принятый для этих ролей стиль общения. Идти против него неразумно, создаёшь о себе плохое впечатление.
В этом плане у нас с вами нет противоречий на самом деле. Всё опять таки сходится к конечному общему образу бренда (если возвращаться к компаниям), просто вот те же уже упомянутые мной Nike могут спокойно использовать тон на "ты" именно в формате "твори, выдумывай, пробуй!" и это воспринимается вполне естественно причём они именно продают в первую очередь.
незнакомец резко вторгся в моё личное пространство
О боже незнакомец в час пик в Московском метро не так посмотрел на меня, а ещё в толкучке задел, грубейшим образом нарушив моё личное пространство.
По резкому сокращению дистанции с клиентом: речи о том, что так должны делать все нет, но и нет речи, что так не может никто делать. Есть сферы где сокращение дистанции вполне может быть быстрым, есть где так не выйдет. В конце концов люди разные и по разному могут реагировать на любые вещи, но всё же упор делается на преобладающую массу.
В любом случае, напоминаю, что мои сообщения описывают тон общения бренда с клиентом в рамках построения имиджа/характера бренда в купе со всеми остальными подходами и т.д. Общая составляющая играет очень важную роль, если общий образ бренда не совместим с обращением на "ты" естественно такой тон будет восприниматься не очень хорошо.
Задача в сокращении дистанции общения, повышение доверия и привлекательности не более.
К тому же грубо говоря все притворяются теми кем не являются хотя бы немного. Это как в любой сфере обслуживания необходимо выглядеть дружелюбно/вежливо/привлекательно для клиента в не зависимости от фактического отношения. По сути все сервисы/ПО своего рода такая же сфера обслуживания (естественно со своими целями).
Любые лишние ёрничанья могут оказаться неуместными в какой-либо ситуации (а мы не знаем, какая ситуация у пользователя — она может быть абсолютно любая).
На этот случай в пользовательском соглашении обычно прописана замечательная строчка про "сервис предоставляется КАК ЕСТЬ и может не соответствовать ожиданиям пользователя", ну естественно и не обязаны соответствовать любым ожиданиям, а то знаете ли, даже на "карцелярит" можно обидеться.
Там всё очень очевидно и определено 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 не подвержены фишингу.
Проблемы с ними были
Ну почему же висит на ДГУ, уже как бы вновь от сети питается. За время пока Nebius AI ещё были просто Nebius, предоставляли мощности израильского дата-центра Nebius Israel и ориентировались на продажу облачной платформы по партнёрке, пока сделку по продаже доводили до фактического заключения вопросы по Финскому ДЦ урегулировались. Собственно Финский ДЦ теперь основной в Nebius AI, там же и парк обновили и статус Nvidia Preferred Partner получили.
Так ок, у нас есть DEK (симметричный), есть KEK (симметричный) по KDF, мы зашифровали клиентский приватный ключ (асимметричный) с помощью KEK (симметричный) по PBKDF2 (пароль знает только пользователь) допустим... Но что с нашим приватным ключом (асимметричный)? Он так же в открытую лежит на статическом хостинге? Или он тоже зашифрован, но данные расшифровки лежат рядом?
В этой схеме просто теряется смысл, по сути любой клиент имеет у себя в наличии сразу два приватных ключа... И вектор атаки очевидно - кража зашифрованного клиентского ключа + пароля для его расшифровки (соц. инженерия, фишинг, зловредные расширения), а серверный приватный ключ уже есть.
Тут без динамической части ну никак не обойтись в принципе, кто-то должен выступать второй стороной ответственной за ключ и хранящей его в тайне.
Вот тут я поправлю, класс может наследовать не только классы, но и функции.
Дело в том, что class это конструкция, которая по факту выполняет роль синтаксического сахара. Внутри это функция с прототипом равным содержимому класса. Вот например:
Если переписать без конструкции class вы получите этого:
Если проверить тип класса из первого примера вы увидите, что результатом будет function.
По этому фактически классы (функции) наследуют функции.
Вообще давайте будем откровенны TOTP (RFC 6238 - май 2011) само по себе является расширением HOTP (RFC 4226 - декабрь 2005), которое просто заменяет инкрементируемый счётчик на временные интервалы (тот же счётчик, только автоматически инкрементируемый в соответствии с временем).
Сама суть HOTP/TOTP в том, что мы просто на просто хешируем счетчик с применением секрета, причём да изначально речь ведётся относительно HMAC-SHA1 и базово библиотеки/приложения HOTP/TOTP реализуют именно его (ну может +SHA256, если повезёт), однако допустимо использование HMAC-SHA256/HMAC-SHA512 да в целом любых HMAC-* хоть HMAC-SHA3-256. Т.е. уже один TOTP другому TOTP рознь как минимум из-за того, что можно менять алгоритм хеширования при сохранении общих принципов.
Далее у нас во всей этой теме с генерацией одноразового кода присутствует секрет, а им нужно обменяться! В простом случае этот секрет просто закодирован в base64 в uri в QR коде. А что если можно поделиться секретом более безопасно, даже явно не раскрывая секрета? Например, можно использовать ECDH с эфемерными ключами - всего две временные пары ключей, в открытую передаются только открытые части, но по результату у обеих сторон есть секрет.
А ещё можно сам одноразовый код отправлять, либо как уже упомянуто по клику на PUSH уведомление (на соответствующую сессионную ссылку из метаданных пуша) или эту ссылку можно ещё показать пользователю в виде QR кода (кстати, а вот и подход Яндекса).
А ещё самое банальное при всей совместимости и базовой реализации - не все приложения базово поддерживающие TOTP умеют в отличные от 6 значений коды, или даже в буквенные коды. (Ладно буквенные коды будем считать расширением, но возможность генерить коды более 6 знаков заложена ещё в HOTP, главное влезть динамическим окном в размерность хеша).
Так вот это к чему я, своё приложение это возможность поменять алгоритм хеширования (даже на экзотический) и/или поменять/обезопасить обмен секретом, а может даже облегчить жизнь пользователю, самостоятельно отправляя одноразовый код на сессионную ссылку из QR. И в определённых случаях это имеет достаточный смысл (сделать явно не как у всех - HMAC-SHA1/256 + QR с секретом).
А на счёт Whatsapp, Telegram - там OTP, но не TOTP/HOTP. У Google Messenger кстати тоже QR код с временным одноразовым значением, но он не для авторизации в аккаунте, а для пеиринга устройств во внутреннем pubsub.
Кстати на счёт Google, да TOTP на доп. факторе у них вполне стандартный, но Google точно так же как Яндекс экспериментирует с собственными транспортами для уже Passkeys (раньше Secure key). TOTP в данном случае уже не так интересен, особенно когда есть по свежее и по интереснее подход полностью на ключах.
А вообще конечно с развитием FIDO/WebAuthn и формированием Passkeys вот этот TOTP может стать просто на просто резервным способом (как одноразовые коды на бумажке) на случай потери доступа к материалам ключей (хотя они ведь будут синхронизироваться).
Ну скажут и скажут, что толку слова уже произнесены, возможно в следующий раз такой ситуации не случится.
В этом и суть мы говорим о программе/сервисе предоставляемом на конкретных условиях, условия заранее оглашены, другое дело на сколько человек в них вдавался. Далее эмоциональное тон программы формируется под конкретную аудиторию, а точнее часть этой аудитории (если хотите "среднее по больнице"), если этот тон не меняется в программе, значит всё хорошо (эмоциональное восприятие соответствует заложенному ожиданию) и всё работает как ожидают разработчики/компания владелец. То, что каждый уже по разному может воспринять тон и это вызовет какую-то не ожидаемую разработчиками эмоциональную реакцию уж извините, но это как с багами да и в целом идеалами - всем угодить не возможно т.к. как минимум все возможные случаи предусмотреть просто не выйдет.
Какое бы нейтральное общение не было, но оно тоже может обидеть, мало говорить сухо/нейтрально без эмоциональной окраски, нужно ещё выбирать формулировки в целом учитывать контекст. Просто банально пример такой: Вот придёт к вам абсолютно нейтральная бумажка об отъеме земли в пользу государства с целью дальнейшей передачи, например РЖД для строительства новой очень важной федеральной магистрали, я сомневаюсь, что она вызовет у вас исключительно радостные эмоции или вообще не вызовет никаких.
Но ведь это же "твори, выдумывай, пробуй!" может быть и при продаже, даже не то что в голове крутиться, а именно так и продаваться.
В этом плане у нас с вами нет противоречий на самом деле. Всё опять таки сходится к конечному общему образу бренда (если возвращаться к компаниям), просто вот те же уже упомянутые мной Nike могут спокойно использовать тон на "ты" именно в формате "твори, выдумывай, пробуй!" и это воспринимается вполне естественно причём они именно продают в первую очередь.
О боже незнакомец в час пик в Московском метро не так посмотрел на меня, а ещё в толкучке задел, грубейшим образом нарушив моё личное пространство.
По резкому сокращению дистанции с клиентом: речи о том, что так должны делать все нет, но и нет речи, что так не может никто делать. Есть сферы где сокращение дистанции вполне может быть быстрым, есть где так не выйдет. В конце концов люди разные и по разному могут реагировать на любые вещи, но всё же упор делается на преобладающую массу.
В любом случае, напоминаю, что мои сообщения описывают тон общения бренда с клиентом в рамках построения имиджа/характера бренда в купе со всеми остальными подходами и т.д. Общая составляющая играет очень важную роль, если общий образ бренда не совместим с обращением на "ты" естественно такой тон будет восприниматься не очень хорошо.
Задача в сокращении дистанции общения, повышение доверия и привлекательности не более.
К тому же грубо говоря все притворяются теми кем не являются хотя бы немного. Это как в любой сфере обслуживания необходимо выглядеть дружелюбно/вежливо/привлекательно для клиента в не зависимости от фактического отношения. По сути все сервисы/ПО своего рода такая же сфера обслуживания (естественно со своими целями).
На этот случай в пользовательском соглашении обычно прописана замечательная строчка про "сервис предоставляется КАК ЕСТЬ и может не соответствовать ожиданиям пользователя", ну естественно и не обязаны соответствовать любым ожиданиям, а то знаете ли, даже на "карцелярит" можно обидеться.