10.11.26 (inclusive)

денежная

Finished product

ICT tasks

Media sphere

Other technological solutions

мобильное приложение + сайт

Ticketon использует номер телефона для верификации и аутентификации: клиент вводит номер, сервис отправляет SMS с OTP , клиент вводит код в форму. Схема рабочая, но ею злоупотребляют. Конкуренты и злоумышленники через ботнет-сеть массово отправляют форму и инициируют SMS на произвольные номера. Цель атаки - искусственно раздуть счёт за SMS без реального использования сервиса. Текущее состояние: CloudFlare Captcha установлена, но боты её обходят; около 30% OTP-отправок - фрод; конверсия отправленных OTP в подтверждённые - 60%; ложные блокировки реальных пользователей не измеряются - метрики нет; фильтрация по коду страны невозможна: аудитория глобальная, малые страны (например, Вьетнам) дают легитимный трафик. Экономический эффект атаки: ~18 000 фрод-отправок в месяц, ~126 000 KZT прямых потерь ежемесячно, плюс риск недоступности сервиса для реальных клиентов при агрессивных блокировках.

Ожидаемый результат Участник предоставляет проектный документ (дизайн-решение) объёмом, достаточным для раскрытия всех пунктов ТЗ, без кода и без прототипа. Документ должен содержать: Описание целевого workflow входа/регистрации по номеру телефона — последовательность шагов, набор каналов верификации (SMS OTP, flash-call, мессенджер-OTP, silent network auth и др.), условия выбора канала и fallback-сценарии при недоступности основного канала. Архитектуру risk-engine: перечень используемых сигналов (поведенческие, device fingerprint, IP/сетевые, история номера, частота запросов и т.п.), принцип скоринга, пороговые значения и соответствующие им действия (пропуск, усиленная проверка, отказ/soft-block), а также обоснование выбранных порогов. Политику rate-limit и блокировок с объяснением, почему она не приводит к массовым ложным срабатываниям на легитимных пользователях из любых стран, включая страны с малым объёмом трафика (например, Вьетнам), где фильтрация по коду страны невозможна. Набор метрик для оценки эффективности решения: доля фрод-отправок от общего числа OTP-запросов, конверсия отправленных OTP в подтверждённые, доля ложных блокировок реальных пользователей, стоимость верификации в расчёте на одного пользователя, а также способ их измерения/мониторинга (дашборд, алерты и т.д.). Обоснование архитектурных trade-offs: почему выбраны именно эти каналы, пороги и политики, какие альтернативы рассматривались и отклонены, какие ограничения и риски решение не закрывает. При изменении канала аутентификации (например, замена части SMS-верификации на email/мессенджер) — план миграции существующей базы клиентов с поэтапными шагами и оценкой трудозатрат в человеко-днях.

Тембаев Тамерлан Бейбутулы