Veriqa, BCP 247 и модель угроз
Сверено с RFC и кодом: 2026-11-05
RFC 10027 — Best Current Practice 247 от IETF о безопасности кросс-девайсных потоков, опубликован в августе 2026 года. Он описывает ту модель угроз, в которой работает Veriqa: вход начинается в браузере на одном устройстве, а подтверждается на телефоне в мессенджере. RFC требует оценить риски до внедрения кросс-девайсного входа и выбрать меры под эту оценку (§2, п. 1 и 4, MUST). Таблица ниже — исходные данные для такой оценки: по каждой из 17 практических мер раздела 6.1 видно, есть ли она в Veriqa и где это проверить.
Это срез сверки с текстом RFC и исходным кодом Veriqa от 5 ноября 2026 года. Источник таблицы и подробный разбор каждой непокрытой меры — страница «Veriqa, BCP 247 и модель угроз» в документации; если они разойдутся, верна документация.
Итог
Из 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 разбор не рассматривает.
Самая сильная схема: passkey вместе с Veriqa
Подтверждение в мессенджере не связано с браузером, где открывается сессия, поэтому сам по себе вход через Veriqa не устойчив к фишингу. Это закрывает сценарий «Passkey вместе с Veriqa»: пользователь входит через мессенджер, заводит passkey по кнопке, которая приходит в тот же чат, а ваше приложение требует ключ до того, как откроет сессию.
- От Veriqa — аккаунт без формы регистрации, запасной канал связи с первого входа и кнопка для заведения ключа в мессенджере.
- От passkey — устойчивость к фишингу: ключ не подписывает запрос для чужого адреса, а вход ключом с другого устройства требует Bluetooth рядом с браузером входа (§6.2.3.3).
Passkey — это способ близости из §6.1.1 и вход, устойчивый к фишингу, который описывает §6.1.15, а RFC советует FIDO2/WebAuthn везде, где устройства это умеют (§6.2.3.5, SHOULD). Защищает обязательный режим ключа — пока вход без ключа открыт, атакующий воспользуется им. Что учесть при заведении первого ключа — в разборе на странице документации.
Модель угроз
В терминах 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 не упоминает):
| Поток Veriqa | Шаблон RFC |
|---|---|
| QR-код или ссылка в мессенджер, письмо в один тап, подтверждение, которое создаёт ваш сервер | User-Transferred Session Data (§3.1.1) — тот же класс, что RFC 8628 |
| Ссылка в письме, отправленном на адрес со страницы входа | Backchannel-Transferred Session (§3.1.2) — класс CIBA |
| Код из письма, введённый на странице входа | User-Transferred Authorization Data (§3.1.3) |
Контекст инициатора в вопросе, короткий срок жизни и одноразовые коды снижают риск, но от пересылки входа не защищают. От неё защищает только обязательный passkey. Фактор места с выбором поверхности по сессии лишь не пускает дальше браузеры вне офиса, и только если ваше приложение открывает доступ после проверки присутствия. Так же действует вход из доверенных сетей: он лишь не пускает браузеры вне этих сетей.
Меры §6.1 в Veriqa
Статусы: покрыто — механизм Veriqa делает то, что описывает мера; частично — покрыта часть меры или только один из потоков; не покрыто — в Veriqa этого нет; вне продукта — мера адресована не серверу авторизации. Таблица оценивает прежде всего вход; подтверждение, которое создаёт ваш сервер, учтено там, где оно дополняет вход. Названия мер — как в RFC.
| § | Мера | Что есть в Veriqa | Статус | Где проверить |
|---|---|---|---|---|
| 6.1.1 | Establish Proximity | Ни одного из четырёх способов RFC — физическое подключение, радио, общая сеть, геолокация — нет. В hop-режиме Veriqa собирает контекст телефона, отсканировавшего QR-код, как сигнал риска, но с устройством входа его не сопоставляет. Фактор места работает уже сейчас как рецепт: после входа человек сканирует QR-код на поверхности в офисе — принтере, экране переговорной, IP-телефоне — и подтверждает в мессенджере, а ваш сервис выбирает поверхность по сети или рабочему месту сессии. Что сделать: passkey, фактор места; направление — уровни привязки | не покрыто | Hop-режим |
| 6.1.2 | Short-Lived/Time-Bound QR or User Codes | Транзакция входа живёт 300 секунд по умолчанию, подтверждение, которое создаёт ваш сервер, — от 60 до 1800 секунд; у одноразовой hop-ссылки свой срок | покрыто | TransactionTtlSeconds, ttl_seconds, HopMode.TokenLifetime |
| 6.1.3 | One-Time or Limited-Use Codes | Транзакция подтверждается один раз, завершённая не повторяется; hop-ссылка и handle связки одноразовые | покрыто | Hop-режим, handle связки |
| 6.1.4 | Unique Codes | Идентификатор транзакции — 256 случайных бит из криптографически стойкого генератора. Транзакция привязывается к аккаунту канала, в котором её открыли первым, — по QR-коду или по ссылке, — и любой другой аккаунт получает отказ; токены по ней выдаются один раз. Так выполняется отказ при повторном предъявлении (MAY), а роль списка использованных кодов играет состояние транзакции. Если hop-ссылку открывают повторно в другом браузере, Veriqa предупреждает об этом пользователя | покрыто | TransactionId.NewId, TransactionService.BindChannelSubjectAsync в исходном коде; HopMode.WarnOnRepeatScan, по умолчанию true — Hop-режим |
| 6.1.5 | Content Filtering | Письма и сообщения фильтруют почтовые сервисы и мессенджеры | вне продукта | — |
| 6.1.6 | Detect and Remediate | Журнал аудита транзакций, пометка необычного контекста входа, отзыв токенов и интроспекция для клиентов с разрешением. Цепочки «обнаружил атаку → отозвал токены, выданные по этому коду → известил серверы ресурсов» нет, пометка необычного контекста по умолчанию выключена, а истории входов для сравнения у неё пока нет; кнопки «это был не я» и CAEP нет. Направление — распознавание аномалий | частично | Аудит, AnomalyDetection:Enabled, EnableRevocation, интроспекция |
| 6.1.7 | Trusted Devices | В ядре реестра доверенных устройств, с которых разрешено начинать вход, нет: вход начинает любой браузер. Подтверждение создаёт только конфиденциальный клиент вашего бэкенда. В сценарии фактора места устройство показа выбирает и регистрирует интегратор. Направление — метка браузера | не покрыто | Получение токена |
| 6.1.8 | Trusted Networks | В ядре списка сетей, из которых разрешено начинать вход, нет; KnownIPNetworks задаёт только доверие к прокси. Сегодня вход ограничивает периметр развёртывания. Что сделать и направление — доверенная сеть |
не покрыто | Инфраструктура |
| 6.1.9 | Limited Scopes | Настройкой: AllowedScopes клиента. Все потоки Veriqa кросс-девайсные, поэтому scopes клиента и есть scopes этих потоков. Сужения по риску — по устройству или месту — нет; RFC его допускает, но не требует («may be further refined») |
покрыто | Клиенты |
| 6.1.10 | Short-Lived Tokens | Настройкой: access-токен живёт 3600 секунд, refresh-токен — 1 209 600 секунд (14 дней), ротация refresh-токена включена | покрыто | Сервер, ротация |
| 6.1.11 | Rate Limits | Лимиты маршрутов (начало входа — 60 в минуту, создание подтверждения — 60 в минуту на клиента, старт входа по Email — 5 в минуту) и лимит на пользователя канала — 5 в минуту. Письма входа считаются и на получателя: 5 в час на адрес, на домен — если включено | покрыто | Veriqa:RateLimit, лимиты, письма на адрес |
| 6.1.12 | Sender-Constrained Tokens | Токены не привязаны к ключу отправителя: DPoP и mTLS нет. Направления на этой странице нет | не покрыто | Поддержка OIDC |
| 6.1.13 | User Education | Обучает своих пользователей сервис интегратора; в RFC это мера уровня MAY | вне продукта | — |
| 6.1.14 | User Experience | Вопрос в мессенджере называет приложение, время запроса, браузер, ОС и регион инициатора и заканчивается советом If it was not you, decline the request. («Если это не вы — отклоните запрос»). Под ним кнопки «Подтвердить ✅» и «Отклонить ❌», отказ отмечен красным крестиком. На странице Veriqa, которая спрашивает «Да» или «Нет», и на странице входа через аккаунт провайдера ответ по умолчанию — «Нет»: эта кнопка залита основным цветом и в фокусе при открытии, «Да» — контурная. На сенсорном экране страница провайдера принимает «Да» только сдвигом шторки. В подтверждении, которое создаёт ваш сервер, текст вопроса пишете вы, и совет об отказе в нём есть, если вы его добавили |
покрыто | Контекст инициатора, Veriqa:LoginConfirmation, ConfirmSlider, шаблоны подтверждения |
| 6.1.15 | Authenticate then Initiate | Для подтверждения, которое создаёт ваш сервер: его начинает бэкенд после входа пользователя, а expected_identities оставляет право подтвердить только владельцу аккаунта. Повторный вход перед рискованной операцией тоже начинает уже вошедший пользователь: рецепт step-up сверяет sub и auth_time в новом id_token. К самому входу мера неприменима: его начинает тот, кто ещё не вошёл. Мера предполагает перед этим вход, устойчивый к фишингу, — такой вход даёт обязательный passkey |
частично | Что проверяете |
| 6.1.16 | Request Initiation Verification | Отдельной ступени с одноразовым кодом нет. Вход по коду из письма — сам поток (§3.1.3), а не добавочная проверка. Направление — уровни привязки | не покрыто | Ссылка, код или оба |
| 6.1.17 | Request Binding with Out-of-Band Data | Нет. Направления на этой странице нет | не покрыто | — |
Что сделать с непокрытыми мерами
Для каждой непокрытой меры документация называет, что можно сделать уже сейчас и какое направление развития у продукта:
- Близость устройств и фактор места — §6.1.1;
- Passkey вместе с Veriqa — §6.1.1, §6.1.15;
- Уровни привязки — §6.1.1, §6.1.16;
- Распознавание аномалий — §6.1.6;
- Метка браузера — §6.1.7;
- Доверенная сеть — §6.1.8.
Лимиты, аудит и ротация токенов перед запуском — в подготовке к продакшну.