Защита OTP от перебора: лимиты, паузы и блокировки

Защита OTP от перебора строится не вокруг одного шестизначного кода, а вокруг всего процесса: выдачи, доставки, проверки, повторного запроса и восстановления доступа. Если ограничить только форму ввода, злоумышленник может распределить попытки по аккаунтам и адресам. Если ограничить только отправку, он продолжит угадывать уже выданный код.

Базовые свойства одноразового кода и его место в авторизации разобраны в статье про OTP SMS для входа. Здесь сосредоточимся на защите от массовых запросов и онлайн-перебора.

Два разных лимита

Система должна отдельно контролировать:

• выдачу — сколько кодов можно запросить для аккаунта, номера, устройства и сетевого источника;
• проверку — сколько вариантов можно ввести для конкретной операции и аккаунта.

Один общий лимит создаёт слепые зоны. Например, атакующий может запросить один код и сделать тысячи попыток проверки. Или наоборот — не угадывать код, а генерировать дорогой поток SMS на множество номеров.

Лимиты работают одновременно на нескольких измерениях. Только IP недостаточен из-за распределённых сетей, только номер позволяет атакующему блокировать жертву, только устройство легко сбрасывается. Решение объединяет сигналы и не раскрывает внутренние пороги в ответе.

Код связан с операцией

OTP должен подтверждать конкретную попытку входа или действие, а не быть универсальным для всего аккаунта. При выдаче создаётся challenge_id, к которому привязаны пользователь, назначение, время, число проверок и состояние.

Код для входа нельзя использовать для смены платёжных данных. Код старой попытки не должен подтверждать новую. После успешной проверки challenge закрывается атомарно, чтобы два параллельных запроса не использовали один OTP дважды.

Сам код не храните открыто. Сохраняйте защищённое проверочное значение и сравнивайте его безопасным способом. В логах SMS фиксируется challenge ID и результат, но не сам секрет.

Срок действия и новый запрос

Короткий срок снижает окно атаки, но слишком короткий ухудшает доступность при задержке сети. Значение выбирают по фактической скорости доставки SMS и пользовательскому сценарию. NIST отмечает, что пользователю нужно достаточное время для переноса одноразового секрета между каналами; одновременно для коротких секретов требуется rate limiting (NIST SP 800-63B).

При повторном запросе заранее определите судьбу старого кода. Наиболее понятная модель — новый challenge инвалидирует предыдущий для той же операции, а пользователь видит, что действителен последний код. Нельзя оставлять длинную цепочку одновременно действующих OTP.

Пауза перед повторной отправкой должна увеличиваться при злоупотреблении. Кнопка «получить снова» блокируется и на клиенте, и на сервере: защита только интерфейса обходится прямым API-вызовом.

Ограничение проверки

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

Не блокируйте аккаунт навсегда только из-за внешних попыток — это создаёт простой способ отказа в обслуживании. Лучше сочетать возрастающую задержку, ограничение конкретного challenge и риск-ориентированную проверку. Успешная аутентификация может сбрасывать часть счётчиков, но журнал подозрительных событий сохраняется.

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

Защита выдачи

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

До SMS можно проверить наличие реальной пользовательской сессии, прохождение предыдущего шага, bot challenge и соответствие риска. Но CAPTCHA не заменяет серверные лимиты: её нужно рассматривать как один слой.

Для повторной выдачи используйте один idempotency key на одну операцию отправки. Двойной клик или повтор HTTP-запроса не должен создавать две SMS.

Риск смены SIM и номера

SMS подтверждает доступ к номеру в данный момент, но не доказывает неизменность личности. NIST относит PSTN-аутентификацию к ограниченным методам и рекомендует учитывать признаки замены SIM, переноса или другого аномального поведения.

Для операций с высоким риском используйте дополнительный фактор и повторное подтверждение привязки. Изменение номера аккаунта — это привязка нового аутентификатора, а не обычное редактирование профиля. Общий уровень риска SMS-фактора рассматривайте вместе с правилами двухфакторной аутентификации через SMS.

Мониторинг атак

Считайте:

• запросы кода на номер, аккаунт, устройство и сеть;
• долю успешных проверок;
• число неверных попыток на challenge;
• повторные отправки и возраст кода при успехе;
• всплески по операторам, странам и диапазонам;
• расходы на недоведённые до входа SMS;
• блокировки и обращения реальных пользователей.

Нормальная базовая линия зависит от продукта. Алерт строят не на универсальной цифре, а на резком отклонении и сочетании сигналов: много выдач, мало успешных входов, новые направления и повторяющиеся шаблоны устройств.

Что тестировать

Проверьте параллельную отправку двух запросов, повтор одного idempotency key, ввод на границе срока, одновременную проверку правильного кода, исчерпание попыток и запрос нового challenge. Убедитесь, что старый код перестаёт работать, а успешная операция выполняется один раз.

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

Восстановление после блокировки

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

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

Разделение кодов и ссылок

Не подставляйте OTP в кликабельную ссылку, которая автоматически завершает критичное действие без дополнительного контекста. Ссылка может попасть в журнал переходов, историю браузера или систему аналитики. Если используется magic link, это отдельный одноразовый токен с собственным сроком, областью действия и защитой от повторного применения.

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

Ротация защитных правил

Лимиты и риск-модель пересматривают по фактическим атакам и обращениям. Изменение порога проходит canary и сравнение ложных блокировок. Слишком строгая защита может снизить взломы ценой потери реальных входов, поэтому обе стороны измеряются одновременно.

Версия правил записывается рядом с решением. Тогда расследование отвечает, почему конкретный запрос был разрешён, а не пытается воспроизвести старое поведение по текущей конфигурации.

Итог

Безопасный OTP — это короткоживущий challenge с ограниченной выдачей и проверкой, атомарным одноразовым использованием и наблюдаемостью. Лимиты действуют на нескольких уровнях, новый код управляемо заменяет старый, а чувствительные операции не полагаются только на владение номером. Такая схема одновременно снижает риск перебора, накрутки расходов и случайных блокировок реальных клиентов.