Итог
Из 17 мер §6.1 Veriqa покрывает 7, частично — 2, не покрывает — 6; ещё 2 адресованы не серверу авторизации. В таблице ниже вы найдёте подробное описание каждой меры и связанных с ней рисков, в том числе — как обеспечить меры, которых нет в ядре Veriqa. Чтобы понять, много или мало покрывает Veriqa, мы решили сравнить, насколько полно эти меры покрывают другие распространённые способы входа. Но RFC 10027 вышел в августе 2026 года, и оценок других способов по нему почти нет, поэтому мы оценили их сами по той же таблице. Код из SMS покрывает 2 меры, частично — 2; ещё 7 мер определяет сервер, который шлёт код, а не сам способ. Вход Google по коду на другом устройстве (RFC 8628) по документации Google покрывает 3 меры, частично — 2; своей оценки по BCP 247 Google не публиковал. В независимом разборе для Amazon Cognito настройки нашлись для 3 мер из 17, для 5 не нашлись, остальные 9 разбор не рассматривает.Модель угроз
В терминах RFC Veriqa — сервер авторизации (Authorization Server). Браузер, где начат вход, — Consumption Device, телефон с мессенджером — Authorization Device. QR-код или ссылка переходят с одного устройства на другое по неаутентифицированному каналу, и проверяет его только человек: «The only mitigation against this unauthenticated channel is the user’s judgment» (§1.1). На этом строится фишинг согласия — Cross-Device Consent Phishing (CDCP). Атакующий сам начинает вход в приложение и под каким-нибудь предлогом передаёт жертве свой QR-код или показывает его на поддельной странице. Жертва подтверждает вход в своём мессенджере, и сессия открывается у атакующего. Аккаунт мессенджера атакующий не получает — он получает вход в приложение. Потоки Veriqa относятся к кросс-девайсной авторизации (§3.1), поэтому второе семейство угроз RFC — фишинг передачи сессии (CDSP, §3.2) — их не касается. Потоки Veriqa соответствуют шаблонам §3.1 так (соответствие выведено из определений RFC, о Veriqa сам RFC не упоминает):
Контекст инициатора в вопросе, короткий срок жизни и одноразовые коды снижают риск, но от пересылки
входа не защищают. От неё защищает только обязательный passkey.
Фактор места с выбором поверхности по сессии лишь не пускает
дальше браузеры вне офиса, и только если ваше приложение открывает доступ после проверки
присутствия. Так же действует вход из доверенных сетей:
он лишь не пускает браузеры вне этих сетей.
Меры §6.1 в Veriqa
Статусы: покрыто — механизм Veriqa делает то, что описывает мера; частично — покрыта часть меры или только один из потоков; не покрыто — в Veriqa этого нет; вне продукта — мера адресована не серверу авторизации. Таблица оценивает прежде всего вход; подтверждение, которое создаёт ваш сервер, учтено там, где оно дополняет вход. Названия мер — как в RFC.Ограничения и направления
У направлений нет сроков, состояние указано у каждого, а у запланированных — ссылка на план релизов.Близость устройств и фактор места
Что не покрыто. Ни одного способа близости из §6.1.1 в Veriqa нет: мессенджер не даёт серверу ни радио, ни общей сети с браузером входа. Что сделать уже сейчас. Соберите фактор места по сценарию «Место и личность»: после входа человек сканирует QR-код на принтере, экране в переговорной или IP-телефоне и подтверждает в мессенджере. Это компенсирующая мера под оценку рисков, а не способ из §6.1.1: она проверяет близость телефона к поверхности места, а не к устройству входа. Атака CDCP держится на расстоянии и масштабе: RFC описывает её как рассылку кодов «to large numbers of users that are geographically distributed» (§6.1.1). QR-код на листе из офисного принтера или на панели в переговорной удалённо не доставить и тысяче адресатов не разослать. Там, где политика периметра запрещает радио, близость FIDO по Bluetooth не работает вовсе (обоим устройствам нужен BLE, §6.2.3.3), а бумажному и экранному QR-коду радио не нужно. Место подтверждает человека, а не сессию. Если сервис выбирает поверхность по сети или рабочему месту, где открыта сессия, сессии вне офиса поверхности не достаётся, и проверку присутствия она не проходит. Это защищает, только если ваше приложение пускает к ресурсам после этой проверки. Если поверхность выбрана по вошедшему, сценарий лишь сужает круг жертв до тех, кто сейчас на месте: при пересылке входа человек подтвердит место у себя в офисе, а сессия останется у атакующего. Направление. Ядро само печатало бы QR-код места через адаптер устройства, а браузер его не показывал бы. Тогда QR-код места ни разу не появлялся бы на экране, и его не увидели бы ни удалённый рабочий стол, ни демонстрация экрана. Состояние: обсуждается.Passkey вместе с Veriqa
Что не покрыто. Подтверждение в мессенджере ничем не связано с браузером, где открывается сессия, поэтому вход через Veriqa не устойчив к фишингу. Что сделать уже сейчас. Сценарий «Passkey вместе с Veriqa»: пользователь заводит passkey по кнопке, которая приходит в мессенджер после входа, а приложение требует ключ до того, как откроет сессию. Ключ не подписывает запрос для чужого адреса. Вход ключом с другого устройства требует Bluetooth рядом с браузером входа (§6.2.3.3). Это способ близости из §6.1.1 и вход, устойчивый к фишингу, который описывает §6.1.15. RFC советует FIDO2/WebAuthn везде, где устройства это умеют (§6.2.3.5, SHOULD). Защищает только обязательный режим и только тех пользователей, у кого он включён: пока вход без ключа открыт, атакующий им и воспользуется. Ключ нельзя давать завести из сессии, открытой через Veriqa: сессия могла достаться атакующему. Следующие ключи добавляйте только после подписи существующим. Слабым местом остаётся заведение первого ключа: ссылка из кнопки действует на предъявителя. Направление. Passkey как ступень уровней привязки.Уровни привязки
Что не покрыто. Подтверждение не связано криптографически с браузером, начавшим вход (§6.1.1, §6.1.16). Что сделать уже сейчас. Passkey вместе с Veriqa. Направление. Спецификация уровней привязки описывает шкалу доверия между браузером, начавшим вход, и тем, кто подтверждает. Её цель — уровень, на котором подтверждение принимается только от того же устройства или от устройства, заранее связанного с ним криптографически. Кандидаты механизма — passkey как дополнительная ступень, ключ канала и ссылка из письма, которую принимает только браузер, начавший вход. Последний вариант убрал бы кросс-девайсность у входа по письму вовсе (§2, п. 2). Без нормативной силы спецификация упоминает и сверку числа — по смыслу §6.1.16, с тем же ограничением, что называет RFC: атакующий, который ведёт жертву интерактивно, попросит у неё и число. Конкретный механизм спецификация не обещает. Состояние: запланировано на релиз после следующего — см. план релизов.Распознавание аномалий
Что не покрыто. Цепочки «обнаружил атаку → отозвал токены, выданные по этому коду → известил серверы ресурсов» нет, кнопки «это был не я» и CAEP тоже нет (§6.1.6). ПереключательAnomalyDetection:Enabled есть, но истории подтверждённых входов, с которой можно сравнивать, ядро
пока не хранит, поэтому пометка не работает и при включённом переключателе.
Что сделать уже сейчас. Следите за журналом аудита транзакций
и отзывайте токены входа, который человек не начинал
(EnableRevocation).
Направление. Veriqa запоминала бы производные неперсональные признаки подтверждённых входов —
страну и тип устройства — и помечала бы вход, который с ними не совпадает. IP, User-Agent и город не
хранились бы, а включалась бы функция по желанию. Это частично покрыло бы обнаружение из §6.1.6, а
отзыв токенов и оповещение серверов ресурсов остались бы за вашим сервисом. Состояние: запланировано
на следующий релиз — см. план релизов.
Метка браузера
Что не покрыто. Вход начинает любой браузер, и Veriqa не отличает браузер, которым человек уже входил (§6.1.7). Что сделать уже сейчас. Ваше приложение знает свои устройства: незнакомому браузеру оно может не открывать сессию без дополнительной проверки, например passkey. Направление. Метка браузера — cookie на адресе Veriqa под Data Protection (шифрование и подпись),HttpOnly, Secure. Незнакомый браузер не получал бы код авторизации, а сессия открывалась бы в
знакомом: вход в нём начинался бы заново по инициативе третьей стороны (OpenID Connect Core, §4).
Веб-пуш свёл бы это к одному нажатию. Браузер атакующего метки этого человека не несёт, а
страница-подделка cookie адреса Veriqa не видит.
Мера покрыла бы §6.1.7 частично. Доверие получает браузер, которым человек уже входил, а не
устройство, зарегистрированное сервером. Cookie — не аттестация, и RFC указывает на это в ограничениях
меры. Предел — новый компьютер и первый вход. Метка надёжна ровно настолько, насколько защищено кольцо
ключей Data Protection: кто читает кольцо, тот подделает и метку. Шифруйте кольцо сертификатом —
Veriqa:DataProtection:CertificateBase64 или :CertificatePath.
Состояние: обсуждается.
Доверенная сеть
Что не покрыто. Списка сетей, из которых разрешено начинать вход, в Veriqa нет (§6.1.8). Что сделать уже сейчас. Сценарий «Вход из доверенных сетей»: ограничьте по сети на обратном прокси маршрут/connect/authorize, которым начинается вход, а
маршруты, на которые приходят телефон и вебхуки каналов, оставьте доступными.
Направление. Запись клиента хранила бы список сетей, из которых разрешено начинать вход. RFC
советует сочетать такую меру с другими (§6.1.8, SHOULD). Состояние: обсуждается.
Служебный адрес
Что не покрыто. Для незнакомого браузера при первом входе проверки нет. Направление. Мессенджер просил бы набрать служебный адрес Veriqa вручную, и Veriqa сверяла бы браузер с тем, что начал вход. Проверка работала бы и при первом входе, но держалась бы на человеке: подделка может увести его на свою служебную страницу. Ни одной меры §6.1 буквально не покрывает — это усиление. Состояние: обсуждается.Цепочка из нескольких каналов
Спецификация цепочки каналов описывает вход, который подтверждается в нескольких каналах подряд. Она защищает от угона одного канального аккаунта: одной украденной сессии мессенджера атакующему не хватит. От пересылки входа цепочка не защищает — каждое её звено пересылается так же, — и строк таблицы не меняет. Собрать её можно уже сейчас по сценарию «Усиленный вход цепочкой каналов». Состояние встроенной поддержки: заморожено.Выбор протокола (§6.2)
§6.2 сравнивает три протокола: RFC 8628, CIBA и FIDO2/WebAuthn. Вход через Veriqa ни один из них не использует: приложение получает токены по коду авторизации с PKCE (OpenID Connect), а кросс-девайсный шаг идёт между страницей Veriqa и мессенджером. RFC 8628 и CIBA описывают, как устройство получит токен; Veriqa отвечает на другой вопрос — чем человек докажет, что это он. FIDO2/WebAuthn RFC советует использовать везде, где устройства это умеют (§6.2.3.5, SHOULD), и допускает в связке с кодом авторизации и PKCE (MAY) — так устроен сценарий «Passkey вместе с Veriqa». Где Bluetooth запрещён или его нет, вход ключом с телефона на компьютер не работает (§6.2.3.3), а вход через мессенджер работает.Дальше
Подготовка к продакшну
Лимиты, аудит, сертификаты и ротация токенов перед запуском.
Контекст инициатора
Что видит человек в вопросе о входе.