Rate limiting de OTP por SMS: límites por usuario, número, IP y dispositivo sin perjudicar la autenticación

Por qué el rate limiting de OTP es una política operativa, no solo un control técnico

El rate limiting OTP por SMS protege varios activos a la vez: el flujo de autenticación, el presupuesto de mensajería, la capacidad operativa y la experiencia de quien intenta acceder legítimamente. Una política demasiado permisiva puede facilitar solicitudes automatizadas, inundar el canal SMS del destinatario y generar tráfico artificial. Una política demasiado rígida puede impedir accesos legítimos o convertirse en una vía de denegación de servicio contra cuentas concretas.

El objetivo no es bloquear indiscriminadamente el SMS. Es decidir, de forma medible y revisable, cuándo permitir una solicitud, cuándo introducir espera o fricción adicional y cuándo restringir temporalmente una acción de riesgo. La unidad de control debe corresponder a la acción protegida y al riesgo observado.

• Separar el abuso de solicitudes del fallo al introducir el código.
• Evitar que una restricción sobre una sola señal, como la IP, determine por sí sola el resultado.
• Medir el efecto de cada límite sobre seguridad, conversión, reenvíos y coste.
• Mantener una vía de recuperación autorizada para quien no pueda completar el flujo habitual.

Qué se debe proteger en un flujo OTP por SMS

Un flujo OTP contiene acciones distintas y no deben compartir necesariamente la misma cuota. Como mínimo, conviene tratar por separado la solicitud inicial del código, el reenvío, la validación del código y el cambio a un canal alternativo o de recuperación. Cada acción tiene una superficie de abuso diferente.

La validación del código requiere una protección especialmente cuidadosa. Cuando el secreto de autenticación es corto, NIST exige un límite efectivo de intentos fallidos consecutivos por cuenta y establece que emitir un código nuevo no debe reiniciar ese contador. El código debe ser de un solo uso y el proceso fuera de banda deja de ser válido si no se completa dentro de diez minutos.

La solicitud o el reenvío no deben modificar por sí solos el estado de una cuenta. Una petición repetida puede justificar una espera, una comprobación adicional o una restricción temporal de la acción, pero no debe producir cambios sensibles hasta que se presente un secreto válido.

• Solicitud inicial: protege contra automatización y generación de tráfico SMS.
• Reenvío: evita duplicados, fatiga del destinatario y presión artificial sobre el transporte.
• Validación: limita adivinación del código y debe conservar el contador de fallos aunque se emita un nuevo código.
• Cambio de canal o recuperación: requiere reglas propias y una evaluación de riesgo proporcional.

Limitar por varias entidades, no solo por dirección IP

Una política basada solo en IP es insuficiente. Un atacante puede repartir intentos entre múltiples direcciones, mientras que usuarios legítimos pueden compartir una misma salida de red. OWASP recomienda asociar el contador de fallos a la cuenta en vez de depender exclusivamente de la IP.

La práctica más útil es combinar dimensiones. La cuenta o identidad de inicio de sesión ayuda a proteger el proceso de autenticación; el número MSISDN controla el destino del SMS; la IP aporta contexto de origen; el dispositivo, la sesión y la campaña o aplicación permiten detectar concentración. Ninguna señal debe interpretarse como prueba concluyente por sí sola.

Antes de aplicar cuotas por número, normalice el destino de forma consistente mediante un esquema internacional de numeración, como E.164. Sin normalización, variantes de representación del mismo número pueden fragmentar contadores o producir decisiones incoherentes.

• Cuenta: esencial para limitar fallos de validación consecutivos y proteger contra fuerza bruta distribuida.
• MSISDN normalizado: útil para controlar solicitudes y reenvíos dirigidos al mismo destino.
• IP: señal complementaria para detectar volumen, automatización o concentración, no identidad del usuario.
• Dispositivo: aporta contexto, pero debe usarse con proporcionalidad porque puede ser compartido.
• Sesión: permite vincular solicitudes y validaciones a un flujo concreto.
• Campaña o aplicación: ayuda a aislar problemas y evitar que una integración afecte a otras.

Cómo elegir ventanas, cuotas y enfriamiento

No existe una cuota universal verificable que sirva para todos los servicios. Los umbrales deben derivarse del riesgo del caso de uso, la población esperada, la tolerancia al fraude, la capacidad del servicio y el impacto de bloquear a una persona legítima. Deben documentarse y revisarse con datos propios.

Una ventana fija es fácil de explicar y auditar, pero puede concentrar solicitudes cerca de sus límites. Una ventana deslizante ofrece una lectura más continua del comportamiento reciente, aunque exige una implementación y una observabilidad más cuidadosas. Un enfriamiento progresivo reduce repetición inmediata sin imponer desde el principio una prohibición larga.

OWASP identifica tres elementos que deben quedar explícitos: el número de fallos que activa la restricción, el periodo en el que se cuentan y la duración de la restricción. También describe el bloqueo exponencial, donde la espera empieza siendo breve y aumenta tras fallos sucesivos.

• Use ventanas simples cuando la prioridad sea explicabilidad operativa y auditoría.
• Use ventanas deslizantes cuando importe evitar picos artificiales alrededor de un reinicio temporal.
• Aplique enfriamiento progresivo a acciones repetitivas antes de recurrir a bloqueos extensos.
• Documente para cada regla: entidad, acción, umbral, ventana, duración, excepción autorizada, responsable y condición de reversión.

Separar solicitud, reenvío y validación evita controles contradictorios

La solicitud inicial y el reenvío consumen capacidad de mensajería; la validación consume capacidad de verificación y afronta el riesgo de adivinación. Un único contador para todo el flujo mezcla causas y dificulta investigar qué ocurre.

Una implementación prudente puede mantener un estado de desafío por sesión o transacción: destino normalizado, cuenta si existe en el flujo, identificador de solicitud, hora de emisión, caducidad, estado de uso, contador de validaciones fallidas y referencias seudonimizadas a señales de riesgo. El secreto OTP no debe registrarse en claro.

La idempotencia también es importante. Si el cliente reintenta una solicitud por una respuesta perdida o una condición de red, el servicio debe poder reconocer la repetición dentro de un contexto controlado en lugar de generar innecesariamente varios mensajes. Esta decisión reduce duplicados y hace más fiable el recuento de solicitudes.

• No reinicie los fallos de validación al generar un nuevo código.
• Marque el código como consumido tras un uso válido para impedir reutilización.
• Haga visible al usuario cuándo puede pedir un nuevo envío, sin revelar información sobre la cuenta.
• Diseñe reintentos técnicos idempotentes para no confundirlos con solicitudes humanas nuevas.
• Aísle las colas de envío de la lógica de autorización: aceptar una solicitud no equivale a confirmar autenticación.

Respuestas seguras y fricción progresiva

La respuesta de un endpoint OTP debe ser neutral sobre la existencia, el estado y el posible bloqueo de una cuenta. OWASP recomienda mensajes consistentes y una temporización uniforme para reducir la enumeración mediante diferencias de contenido o tiempo.

Cuando una señal de riesgo aumenta, es preferible aplicar fricción progresiva antes que un bloqueo amplio. Por ejemplo, una espera visible antes del reenvío, una comprobación adicional contra automatización o una revisión de riesgo pueden ser medidas proporcionadas. CAPTCHA puede actuar como defensa en profundidad y puede introducirse después de algunos fallos, no necesariamente en el primer intento.

Las restricciones deben impedir abuso sin permitir que un tercero deje fuera a usuarios legítimos. Por ello, no conviene aplicar una suspensión extensa de cuenta únicamente porque alguien ha solicitado códigos repetidamente para ese destino.

• Use mensajes como: “Si el flujo es válido, recibirás instrucciones o podrás continuar cuando finalice la espera”.
• Muestre una cuenta atrás de reenvío asociada a la transacción, no información sobre si existe una cuenta.
• Eleve la fricción según repetición, velocidad y concentración de señales, no por una única observación aislada.
• Reserve restricciones de mayor impacto para riesgo corroborado y durante una duración definida.
• Ofrezca recuperación autorizada cuando el canal habitual no sea viable.

Señales que justifican revisar o endurecer controles

Las señales de riesgo sirven para priorizar revisión y ajustar controles; no equivalen por sí solas a una identidad o a una prueba de fraude. OWASP recomienda tratar como no confiables los datos recibidos desde clientes, dispositivos, redes o servicios externos, porque pueden faltar, repetirse, modificarse o falsificarse.

Busque patrones de concentración y repetición: muchas solicitudes para un mismo destino, actividad rápida desde una fuente, secuencias de reenvío sin validación, fallos de código persistentes o volumen anómalo dentro de una misma aplicación. En canales PSTN, NIST recomienda valorar indicadores como cambio de dispositivo, cambio de SIM, portabilidad del número u otro comportamiento anómalo antes de enviar el secreto.

El dispositivo requiere un tratamiento especialmente prudente. Puede aportar una señal útil frente a abuso a gran escala, pero los dispositivos también se comparten. No convierta una asociación de dispositivo en una prohibición automática de acceso para múltiples usuarios legítimos.

• Concentración: repetición sobre una cuenta, un número, una sesión o una aplicación.
• Velocidad: cadencia incompatible con el uso normal esperado del flujo.
• Patrón de fallo: múltiples validaciones erróneas o solicitudes sin finalización.
• Destino: cambios inusuales en el patrón de destinos dentro de una aplicación.
• Riesgo contextual: indicadores de cambio de dispositivo, SIM o portabilidad, tratados como señales y no como certezas.
• Calidad de señal: datos incompletos o no confiables deben reducir la confianza de la decisión, no endurecerla automáticamente.

Qué registrar sin almacenar más datos de los necesarios

Los registros permiten explicar una decisión, investigar abuso y detectar falsos positivos. OWASP recomienda registrar éxitos y fallos de autenticación, intentos de superar límites y actividad sospechosa de lógica de negocio, utilizando una taxonomía consistente y documentada.

Para cada evento, conserve el contexto de cuándo, dónde, quién y qué ocurrió: marca temporal, identificador de interacción, acción, resultado, regla aplicada y nivel de confianza. Use identificadores seudonimizados o referencias protegidas cuando sea adecuado para la cuenta, el número, el dispositivo o la sesión.

No registre secretos OTP, contraseñas, tokens de acceso, valores de sesión ni datos personales innecesarios. Aplique enmascaramiento, hash, cifrado o seudonimización según el caso y asegure que los controles de acceso a logs sean coherentes con la sensibilidad de los datos.

• ID de interacción o transacción para correlacionar solicitud, envío y validación.
• Marca temporal, acción, resultado y motivo de la decisión.
• Identificador de regla, entidad limitada y estado de la cuota, evitando exponer secretos.
• Referencia seudonimizada al destino y a otras señales necesarias para correlación.
• Contexto técnico de origen solo en la medida necesaria para seguridad e investigación.
• Eventos de excepción, revisión manual y reversión para mantener trazabilidad.