Опять же провал воображения, если представить, что утечка ключа — единственный способ испортить процесс.
Им необходимо реализовать API, позволяющий стороннему менеджеру паролей перехватывать хранилище закрытых ключей, или разрешить стороннему плагину быть полным аутентификатором — создать пару ключей, подтверждение подписи, проверку пользователя, и т. д.
Если Apple разрешит хранить только закрытые ключи в iCloud, мне будет сложно рекомендовать ключи доступа группе пользователей, использующих iPhone и компьютеры с Windows. Эти люди застрянут, создавая один ключ доступа для каждой экосистемы и/или надеясь, что восстановление учетной записи сработает.
Клиент вредоносный сервер <> истинное приложение
Вредоносный сервер связывается с приложением от имени клиента, запрашивает у клиента подпись, а затем передает ее обратно приложению. Для этого им не нужен закрытый ключ, им просто нужно, чтобы приложение запросило ключ, а клиент ответил правильным ключом. Этот механизм можно в определенной степени смягчить на стороне сервера, но это относится к паролям и ключам доступа.
Тип фишинга, который это предотвращает, — это веб-сайт статического сбора учетных данных, который выдает себя за страницу входа в систему, но на самом деле ничего не передает на реальный сайт. И это также упускает из виду суть вашего следующего абзаца.
«Точка использования» находится в режиме реального времени. Атаки повторного воспроизведения редки и могут быть смягчены на стороне веб-приложения. Подстановка учетных данных не является «точкой использования» — она используется всякий раз, когда ее хочет использовать злоумышленник, а не клиент.
Фишинг определенно широко распространен, но я никогда не говорил, что это не так. Я говорю, что при резервном копировании паролей ключи доступа не помогают смягчить указанные фишинговые атаки, поскольку резервная копия становится жертвой той же методологии атаки, что и старый механизм аутентификации.
Национальные государства определенно нацелены на техническую поддержку, притворяющуюся сотрудниками, для перезагрузки устройств / MFA. Так что понятия не имею, о чем вы здесь говорите.
Я прекрасно понимал, что ты иронизируешь. Я ответил сардонически, так как план по удалению паролей никто не показывал (до стр. 14).
Им необходимо реализовать API, позволяющий стороннему менеджеру паролей перехватывать хранилище закрытых ключей, или разрешить стороннему плагину быть полным аутентификатором — создать пару ключей, подтверждение подписи, проверку пользователя, и т. д.
Если Apple разрешит хранить только закрытые ключи в iCloud, мне будет сложно рекомендовать ключи доступа группе пользователей, использующих iPhone и компьютеры с Windows. Эти люди застрянут, создавая один ключ доступа для каждой экосистемы и/или надеясь, что восстановление учетной записи сработает.
Да, именно поэтому в мою учетную запись Houzz можно войти только через мой Mac/iPhone, а не через мое устройство Windows :/
Потому что, когда клиент что-то подписывает, он ищет аутентификатор FIDO2 на основе домена MITM. Если его нет, вы не получите аутентификацию FIDO2. Если у него есть аутентификация FIDO2, она все равно не будет соответствовать той, которую ожидает реальный сервер, потому что у него есть собственный домен. Таким образом, имеющийся у него открытый ключ не будет совпадать с закрытым ключом, используемым для подписи вещей.
Поэтому добавьте свое устройство Windows с помощью Windows Hello. Edge, Firefox и Chrome поддерживают это. Это одна из немногих вещей, в которых Firefox находится на должном уровне — они поддерживают ключи, специфичные для платформы, с помощью Windows Hello. Однако совместимость между браузерами не гарантируется.
И вот что я пытаюсь вам объяснить: было бы легко пройти аутентификацию на существующем устройстве и использовать его. устройство для добавления другого открытого ключа, который генерируется на другом, новом устройстве и отправляется на старое устройство каким-либо означает. Например, я мог бы создать новую пару секретный ключ/открытый ключ на своем настольном компьютере, отправить открытый ключ на свой ноутбук, войти в систему с помощью своего ноутбука и добавить открытый ключ рабочего стола. Я постоянно делаю подобные вещи с SSH.
Здесь нет никаких технических препятствий. Если это невозможно с помощью ключей доступа, то это по вашему выбору.
За исключением Android, я практически вычеркнул Google из своей жизни. Моя единственная причина иметь учетную запись Google — это приложения и обновления Play Store. Вот и все.
Клиент вредоносный сервер <> истинное приложение
Вредоносный сервер связывается с приложением от имени клиента, запрашивает у клиента подпись, а затем передает ее обратно приложению. Для этого им не нужен закрытый ключ, им просто нужно, чтобы приложение запросило ключ, а клиент ответил правильным ключом. Этот механизм можно в определенной степени смягчить на стороне сервера, но это относится к паролям и ключам доступа.
Даже если у вас есть другой ключ доступа к вредоносному серверу, вы подпишете утверждение с использованием nonce вредоносного сервера, которое истинное приложение отклонит, поскольку у него другой открытый ключ.
Безопасность во многом обеспечивается тем фактом, что пары ключей никогда не используются повторно — они всегда генерируются заново для каждого сервера.
Протоколы FIDO используют стандартные методы шифрования с открытым ключом для обеспечения более надежной аутентификации и изначально разработаны для защиты конфиденциальности пользователей.
fidoalliance.org
«Устройство использует идентификатор учетной записи пользователя, предоставленный службой, для выбора правильного ключа и подписи запроса службы».
Идентификатор предоставляется службой или считывается клиентом? Потому что, если это работает так, как вы говорите, тогда да, я согласен, но в документации FIDO я понял, что это означает, что служба отправляет данные для того, какой ключ использовать - и в этом случае MITM все равно будет работать.
Кстати, я попробовал демо-версию на passkeys.io, и Firefox, и Vivaldi на Manjaro хотят, чтобы я подключил ключ безопасности. Я не уверен, является ли это ограничением браузеров или демо-версии.
Спасибо! Это должно быть в статьях, посвященных паролям, а не на странице 14 раздела комментариев.
Я не использую Windows Hello, поскольку это рабочий стол, и я не использую веб-камеру.
Теперь, когда у вас есть информация, собираетесь ли вы опубликовать, что ваши крики были неправильными или дезинформированными?
Windows Hello может использовать PIN-код, сканер отпечатков пальцев (даже USB-сканер, у меня есть парочка). забрать на Amazon по 25 австралийских долларов за штуку или что-то в этом роде) или аппаратный ключ (так что будет некоторая избыточность на... вместо прямого использования аппаратного ключа...)
На самом деле я уже довольно долго пытался найти спецификации через Google, но безуспешно. Вероятно, потому, что в спецификациях отсутствует SEO, и ни в одном из сообщений в блоге они не упоминаются.
Протоколы FIDO используют стандартные методы шифрования с открытым ключом для обеспечения более надежной аутентификации и изначально разработаны для защиты конфиденциальности пользователей.
fidoalliance.org
«Устройство использует идентификатор учетной записи пользователя, предоставленный службой, для выбора правильного ключа и подписи запроса службы».
Идентификатор предоставляется службой или считывается клиентом? Потому что, если это работает так, как вы говорите, тогда да, я согласен, но в документации FIDO я понял, что это означает, что служба отправляет данные для того, какой ключ использовать - и в этом случае MITM все равно будет работать.
Основано ли это на предположениях, или вы можете указать на что-то из FIDO, подтверждающее ваше утверждение о том, что закрытый ключ доступен во время аутентификации и регистрации? То, как я прочитал спецификации WebAuthn, ваш пост, получивший положительные голоса, на 100% неверно. То, как я читаю спецификации телефона или другого устройства, хранящего закрытый ключ, просто доказывает, что у него есть закрытый ключ (возможно, ответив на запрос поставщика своим открытым ключом?). Единственное, что сервер получает от транзакции, — это своего рода криптографическая проверка правильности закрытого ключа. Во время этой транзакции закрытый ключ остается на 100 % на устройстве. Именно так происходит аутентификация, при этом закрытый ключ никогда не покидает устройство (за исключением уже отмеченного случая, когда большой двоичный объект E2EE синхронизируется с доверенными устройствами пользователя).
На самом деле я уже довольно долго пытался найти спецификации через Google, но безуспешно. Вероятно, потому, что в спецификациях отсутствует SEO, и ни в одном из сообщений в блоге они не упоминаются.
Хорошо, что аутентификаторы FIDO2 не являются USB-накопителями. Я думаю, что это USB-HID. Тот, который сейчас подключен к моему ноутбуку, определенно кажется таковым.
На самом деле я уже довольно долго пытался найти спецификации через Google, но безуспешно. Вероятно, потому, что в спецификациях отсутствует SEO, и ни в одном из сообщений в блоге они не упоминаются.
Зачем им разрабатывать спецификацию безопасности таким образом? Серьезно? Сотни людей в крупных интернет-корпорациях работали над этим годами, но вот Джаррекс из Интернета. кто может обнаружить проблему, даже не читая никакой документации (потому что не смог найти ее с помощью поиска) двигатель).
Круто, не знал, что PIN-код работает. Я думал, что Hello всегда привязан к биометрии, которой у меня не было на этом компьютере.
Не уверен, что я правильно понимаю: если вредоносный сервер получает одноразовый номер приложения, он пересылает его клиенту (потому что он притворяется вредоносный сервер), а затем берет сигнатурный ответ клиента и пересылает его приложению, что предотвращает это в вашем сценарий? В этом сценарии вредоносному серверу не нужен закрытый ключ (не нужно ничего подписывать), ему просто нужно переключиться между клиентом и приложением.
Я собираюсь остановить тебя прямо здесь. В миллионный и первый раз, если Google, Microsoft, Google и 1Password et al. все удалите свой ключ доступа, вы ПРОСТО ВХОДИТЕ В СВОЮ АККАУНТ GOOGLE, ИСПОЛЬЗУЯ СВОЙ ПАРОЛЬ. Какой бы риск блокировки вы ни испытывали ранее при использовании паролей, это точно такой же риск, с которым вы сталкиваетесь, сохраняя ключ доступа. Абсолютно нулевой прирост. Пожалуйста, перестаньте повторять глупости.
Теперь, когда вы раскритиковали плохое SEO спецификации WebAuthn, не могли бы вы сказать, планируете ли вы публично исправить себя?
Хм, только что просмотрел все статьи, и ни одна из них не объясняет, как это предотвращает атаки MITM. Если у меня есть веб-сайт и я обманом заставляю вас его посетить, я не вижу причин, по которым он не будет подвержен атакам MITM.
