Rate limits и защита OTP

Какие угрозы решают лимиты

У OTP есть два основных класса злоупотреблений. Первый — массовый вызов send, который расходует баланс, создаёт нежелательные сообщения и нагружает поддержку. Второй — перебор verify, когда атакующий пытается угадать действующий шестизначный код.

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

Ограничения для send

Серверный cooldown повторной отправки — основа защиты. Кнопка с таймером во фронтенде улучшает UX, но сама по себе не защищает API: атакующий может обойти интерфейс.

Комбинируйте счётчики:

• на телефонный номер;
• на аккаунт или сессию;
• на IP и при необходимости подсеть;
• на API-ключ или компанию;
• на purpose;
• на общий объём за короткое и длинное окно.

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

Ограничения для verify

Код Cascade содержит 6 цифр, поэтому пространство вариантов конечно. Связывайте попытку с номером, активным challenge и purpose. После нескольких неверных значений увеличивайте задержку или аннулируйте challenge.

Не разрешайте бесконечно проверять один код до истечения 5 минут. Время действия ограничивает срок, но не количество попыток внутри этого срока.

Успешный код должен стать недействительным немедленно. Повторный verify того же значения не должен снова подтверждать действие.

Почему одного IP недостаточно

В офисе, мобильной сети или за NAT много пользователей могут иметь один внешний IP. Жёсткий лимит только по адресу создаст ложные блокировки. При этом злоумышленник может распределить запросы между разными адресами.

IP остаётся полезным сигналом, но работает лучше вместе с номером, аккаунтом, ключом и поведенческими признаками.

Как обрабатывать 429

HTTP 429 Too Many Requests означает, что немедленный повтор запрещён. Клиент должен:

1. остановить автоматический цикл;
2. сохранить request ID для диагностики;
3. показать пользователю понятный таймер;
4. подождать разрешённый интервал;
5. повторить запрос ограниченное число раз.

Для временных 5xx применяют экспоненциальный backoff с верхней границей и небольшим jitter. Для 401 и большинства 422 автоматический повтор без изменения запроса бессмысленен.

Безопасный пользовательский интерфейс

Кнопка resend должна быть недоступна до завершения cooldown. После нажатия не создавайте параллельные запросы и не меняйте таймер до ответа сервера.

Текст ошибки не должен раскрывать наличие аккаунта. Для входа и восстановления используйте нейтральные формулировки. Показывайте, когда можно попробовать снова, но не публикуйте внутренние пороги защиты.

Мониторинг

Отслеживайте:

• число send и verify по времени;
• долю 429, 422 и 401;
• номера и ключи с аномальной активностью;
• расход кредитов без последующего verify;
• частоту resend;
• изменение успешной проверки;
• нагрузку по IP и подсетям.

Алерт должен помогать действовать: временно ограничить ключ, связаться с компанией, проверить утечку секрета или скорректировать слишком строгий порог.

Чеклист реализации

• Send и verify имеют независимые правила.
• Cooldown проверяется на сервере.
• Счётчики комбинируют номер, аккаунт, IP, ключ и purpose.
• Код имеет ограничение попыток внутри TTL.
• После успеха код нельзя использовать повторно.
• 429 не запускает немедленный retry.
• 5xx обрабатывается ограниченным backoff.
• Интерфейс показывает таймер без раскрытия внутренних порогов.
• Аномалии и расход баланса попадают в алерты.

Текущие ответы API описаны на страницах rate limits и ошибок. Общие меры собраны в материале «Безопасность OTP».