Что такое nonce?

Одноразовое или уникальное значение, которое помогает связать конкретный протокольный обмен и защищаться от повторного использования.

Зачем Challenge single-use?

Чтобы успешный ответ нельзя было просто повторно использовать для новых запросов.

Можно ли проверять HTTP-доступность картинки при каждом запросе?

Не стоит: это лишняя нагрузка и зависимость. Такая проверка подходит для diagnostics/maintenance/acceptance.

Что происходит, если image bank сломан?

Корректная система показывает DEGRADED/ERROR и использует здоровый fallback, а не сообщает READY.

Challenge-response: как работает антибот-проверка, токены, nonce и replay protection

Challenge-response: как устроена проверка «вызов — ответ» в антиботе

Challenge-response — это протокол, в котором сервер выдаёт клиенту ограниченный по времени вызов, а затем проверяет ответ и контекст. Для безопасности важна не только сама задача, но и связка challenge ID, nonce, срока жизни, single-use и серверной валидации.

База знаний AntiPFОбновлено 16.09.202610–14 минут

Базовый flow Challenge-response

Сервер принимает запрос и по policy решает выдать Challenge.
Создаёт challenge state: CID/token, nonce, expiry и разрешённый provider/asset context.
Клиент отображает задачу и отправляет ответ.
Сервер валидирует token, expiry, nonce, replay state и сам ответ.
При успехе выдаётся ограниченная авторизация/continuation state; событие попадает в reputation/trace.

Зачем opaque token

Клиент не должен получать внутренние признаки Risk Engine, секреты или SQL/DB identifiers, которые можно подделать. Opaque token связывает публичный протокол с серверным состоянием без раскрытия деталей.

Replay protection и single-use

nonce должен быть уникальным в нужной области;
token имеет срок жизни;
успешно использованный challenge нельзя бесконечно повторять;
повторная отправка должна иметь отдельный event/reason;
state transition должен быть устойчив к конкурентным запросам.

Почему assets тоже часть протокола

Для image-based Challenge недостаточно записи в БД: активный asset должен существовать, читаться и реально отдаваться HTTP-сервером. Иначе пользователь получает сломанную задачу, а система не имеет права считать subsystem READY.

Fallback и отказоустойчивость

Главный инвариант

Ошибка provider/asset не должна превращаться в бесконечную последовательность Challenge → reload → Challenge. Нужен здоровый fallback или безопасная деградация.

HTTP self-check assets не нужен на каждом visitor request: его место — installer acceptance, diagnostics, maintenance и scheduled health.

Как это связано с AntiPF

Challenge Protocol v2 в AntiPF

AntiPF сохраняет opaque tokens, single-use, CID+nonce, Visitor Authorization и recovery-механику. В 10.050 readiness дополнительно зависит от реальной доступности активных assets и fallback.

МодульChallenge Studio →СтатьяЧто такое CAPTCHA →СтатьяCAPTCHA vs AntiBot →МодульDecision Trace →