Кратко

  • В сценариях RFC 10027 пользователь действительно проходит аутентификацию, но разрешает поток, начатый устройством атакующего. Недостаёт доказательства связи между инициатором и решением.
  • Действительный QR-код или пользовательский код может обозначать ожидающую транзакцию. Он не доказывает, кто его показал, ожидал ли пользователь запрос и какому клиенту достанутся токены.
  • Daniel Fett — соавтор BCP вместе с Pieter Kasselman и Filip Skokan. Документ сочетает выбор протокола, близость устройств, доверие, ограничение полномочий, обнаружение и восстановление, прямо указывая пределы каждого слоя.

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

Consumption Device начинает запрос и должен получить возможность действовать. Authorization Device подтверждает пользователя и собирает согласие. Между ними человек переносит QR-код, короткий код или смысл push-уведомления. RFC 10027 указывает, что этот канал контекста часто не аутентифицирован.

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

MFA сработала — полномочие ушло не туда

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

RFC называет выдачу доступа Cross-Device Consent Phishing. В Cross-Device Session Phishing пользователь передаёт артефакт для переноса уже аутентифицированной сессии. Добычей становится не обязательно пароль, а access token, refresh token или рабочая сессия. Поэтому смена пароля сама по себе не подтверждает устранение последствий.

Код остаётся доказательством в узком смысле. Он может быть правильно сформирован, уникален и не просрочен. Но это не устанавливает предъявителя, намерение, физическую близость, разумность scope или клиента-получателя. Подлинная серверная ссылка способна работать внутри вымышленной человеческой истории.

Метод Daniel Fett: не расширять свойство шага

На личном сайте Fett представляет себя консультантом по безопасности идентичности и веб-протоколов, участвующим в OAuth и OpenID Connect в OpenID Foundation и IETF. Его запись IETF включает RFC об идентификации issuer, proof of possession и безопасности OAuth. RFC 10027 написан тремя авторами; биография не делает Fett единоличным автором и не даёт ему контроля над развёртываниями.

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

Слово «аутентифицирован» требует продолжения: кто, перед кем и для какой транзакции? Личность пользователя, инициатор, контекст, намерение, grant, получатель токена и доступ к ресурсу — разные утверждения. Сервер может быть настоящим, а запрос — атакующего. Sender-constrained token может быть связан именно с ключом злонамеренного клиента.

Слои защиты и их остаточный риск

Короткоживущие, одноразовые и уникальные коды уменьшают повторное использование. Интерактивный атакующий способен создать код после ответа жертвы. Rate limit мешает масштабу, но слабее против точечной атаки. Обучение полезно, однако злонамеренный поток на настоящей странице бывает практически неотличим от обычного.

Близость через BLE, NFC, UWB, общую сеть или местоположение затрудняет удалённую подмену. VPN, подмена координат, NAT, мобильная сеть и законное удалённое одобрение не позволяют считать близость эквивалентом намерения. Сервер проверяет сигналы, но не измеряет физическое расстояние напрямую.

Право инициировать только с управляемых устройств или доверенных сетей сужает поверхность. Доверие требует регистрации, attestation, обновлений и отзыва. Скомпрометированное доверенное устройство всё равно опасно. Малые scopes и короткие токены уменьшают ущерб после ошибочного grant. Привязка к отправителю затрудняет перенос токена, но не мешает клиенту атакующего использовать собственный ключ.

Поэтому выбор протокола — часть модели риска. RFC предпочитает FIDO cross-device authentication там, где устройства связывают origin и BLE-близость. CIBA подходит при существующем канале сервера к пользователю, но требует защиты от неожиданных запросов. OAuth Device Authorization Grant работает на наименее оснащённых устройствах и должен применяться, когда более сильные варианты невозможны; для чувствительных и критических ресурсов нужны дополнительные меры.

Что должно следовать за записью «одобрено»

Running-Code Primacy Heng Lu даёт подходящий критерий: декларация интерфейса не равна эксплуатационному результату. Важно, какой клиент получил какую возможность и что сделал дальше.

Надёжная квитанция связывает идентичность и состояние инициатора, Authorization Device и метод, контекст на обоих экранах, scope, признаки близости или device binding, решение, получателя и ограничения токена, первое использование, аномалии, отзыв и восстановление. Для приватности данные нужно минимизировать и защищать. Зелёная отметка не заменяет их.

Ответственность следует рычагам. Продукт решает, оправдано ли удобство. Команда identity выбирает протокол и права. Устройства и сеть управляют доверием. Fraud-команда обнаруживает аномальные запуски. Resource Server применяет ограничения. Поддержка и Incident Response отзывают grants и сессии. Нельзя возлагать на пользователя единоличную аутентификацию канала, который архитектура оставила без неё.

Вывод не в том, что QR-коды запрещены. Видимая передача ссылки ещё не является аутентифицированным отношением.

Источники