Ventanas de supresión de OTP por SMS: cómo reducir reenvíos duplicados sin bloquear a usuarios legítimos

El problema operativo: los reenvíos no son una simple función de UX

Cuando una persona solicita varias veces un código OTP por SMS, el sistema puede generar códigos simultáneos, aumentar el coste de mensajería, crear confusión sobre cuál debe introducirse y ampliar la superficie de abuso. También puede elevar los contactos a soporte si el usuario recibe mensajes retrasados o si un código anterior deja de funcionar sin una explicación clara.

Sin embargo, suprimir cada solicitud repetida de forma rígida también puede impedir una autenticación legítima. La demora puede estar en la red, en el proveedor de mensajería, en el terminal o en la conectividad del usuario. Además, hay usuarios que no pueden depender siempre de cobertura móvil y deben disponer de alternativas de autenticación autorizadas.

La ventana de supresión OTP SMS es un control operativo que decide si una nueva solicitud debe aceptarse, retrasarse o no generar otro SMS. No sustituye los controles de seguridad del OTP: debe funcionar junto con la vigencia limitada del secreto, la aceptación de un solo uso, la limitación de intentos de verificación y la evaluación de riesgo.

• Objetivo de seguridad: limitar el abuso de solicitudes y de intentos de comprobación.
• Objetivo operativo: evitar mensajes duplicados y estados inconsistentes.
• Objetivo de experiencia: informar de la espera sin revelar si existe una cuenta o un número.
• Objetivo de accesibilidad: ofrecer métodos alternativos cuando SMS no sea utilizable.

Qué gobierna una ventana de supresión

Una ventana de supresión no debe responder únicamente a la pregunta «¿cuánto tiempo ha pasado desde el último clic?». Debe gobernar una decisión completa: si se crea una solicitud nueva, si se reutiliza una solicitud vigente, si se pospone el envío, si se cancela un intento pendiente o si se dirige al usuario a una alternativa autorizada.

La decisión debe ser determinista en el servidor. La interfaz puede mostrar una cuenta atrás, pero no debe ser la autoridad sobre cuándo se permite un reenvío. El servidor conserva el estado de la solicitud, evalúa límites y riesgo, emite el código y decide qué secreto puede verificarse.

Conviene definir explícitamente el comportamiento de los códigos anteriores. Una política frecuente es invalidar los códigos previos cuando se emite uno nuevo para la misma finalidad y solicitud de autenticación. Si se adopta esa política, debe comunicarse al usuario y aplicarse de forma atómica para evitar que dos códigos queden válidos por una condición de concurrencia.

• Permitir: no existe una solicitud vigente que deba suprimirse y los límites permiten el envío.
• Retrasar: la solicitud es legítima, pero sigue vigente el enfriamiento de reenvío.
• Suprimir: se detecta duplicidad, una operación equivalente ya está en curso o se supera una restricción aplicable.
• Escalar o cambiar de canal: el riesgo, la accesibilidad o un fallo técnico confirmado justifican una ruta alternativa autorizada.

Separar los tres temporizadores esenciales

La validez del código, el enfriamiento de reenvío y la expiración de la solicitud son temporizadores distintos. Mezclarlos suele producir dos errores: mantener un código aceptable más tiempo del necesario o negar un reenvío legítimo porque se confunde el tiempo de espera con la vigencia criptográfica.

La validez del código define hasta cuándo el verificador puede aceptar el secreto. NIST establece que la autenticación fuera de banda debe completarse dentro de 10 minutos y que el mismo secreto solo debe aceptarse una vez durante su periodo de validez. Una implementación puede elegir una vigencia más corta si su análisis de riesgo y su experiencia de usuario lo justifican.

El enfriamiento de reenvío define cuánto debe esperar la persona antes de pedir otro SMS. Es una decisión operativa separada: debe reducir pulsaciones repetidas y tráfico duplicado, sin tratarse como prueba de que el primer SMS no llegará. La expiración de la solicitud determina cuándo se cierra la transacción de autenticación y se exige iniciar un flujo nuevo.

• Validez del código: controla la aceptación del secreto y su resistencia a repetición.
• Enfriamiento de reenvío: controla la frecuencia de nuevos envíos.
• Expiración de solicitud: cierra el contexto transaccional y evita estados indefinidos.
• Límite de intentos de verificación: controla los intentos fallidos y no debe reiniciarse al emitir otro código.

Modelo de estados para una solicitud OTP

Modele la solicitud OTP como una transacción interna con un identificador único. Los estados del proveedor de mensajería deben asociarse a esa transacción, pero no deben controlar por sí solos la validez del código ni el resultado de autenticación.

Un modelo mínimo puede incluir creada, aceptada, enviada, estado final informado, verificada, expirada y cancelada. El estado «estado final informado» representa que se recibió una actualización terminal desde el sistema de mensajería, pero no afirma que el usuario haya visto, leído o usado el SMS.

Las transiciones deben ser controladas por el servidor e idempotentes. Por ejemplo, una verificación correcta debe cerrar la posibilidad de reutilizar el secreto, incluso si después llega un callback de entrega retrasado. Del mismo modo, una actualización externa fuera de orden no debe reabrir una solicitud expiraba, cancelada o ya verificada.

• Creada: existe el contexto de autenticación, pero todavía no se ha aceptado el envío.
• Aceptada: se superaron las validaciones internas y se decidió iniciar el envío.
• Enviada: el sistema registró la emisión hacia la conectividad de mensajería.
• Estado final informado: se recibió un estado terminal externo, cuya semántica debe conservarse sin sobrerinterpretarla.
• Verificada: el secreto válido fue devuelto y aceptado una sola vez.
• Expirada o cancelada: la solicitud ya no puede producir una autenticación correcta.

Evidencias para decidir un reenvío y límites de los DLR

La evidencia más sólida para la autenticación es la verificación exitosa del secreto dentro de su periodo de validez. Un evento de transporte no sustituye la respuesta explícita del usuario ni prueba que el código haya sido recibido, leído o introducido en el terminal.

Para decidir un reenvío, ordene las evidencias por su función. Los eventos internos indican si ya existe una solicitud activa, si un código continúa vigente, si hubo una verificación o si se alcanzaron límites. La respuesta de envío permite saber si el sistema de mensajería aceptó o rechazó la operación conforme a su interfaz. Los DLR pueden aportar información de estado de entrega reportada, pero su interpretación depende de la semántica disponible en la cadena de mensajería.

Un DLR informado como entregado no debe tratarse como confirmación independiente de recepción física, lectura o posesión legítima del terminal. Un DLR pendiente tampoco prueba un fallo. La política de supresión debe evitar tanto el reenvío inmediato por falta de DLR como el bloqueo automático porque exista un DLR entregado.

• Use el estado interno para conservar la autoridad de la decisión.
• Conserve la respuesta de envío y su identificador de correlación.
• Almacene el DLR original, su momento de recepción y su relación con el mensaje.
• No convierta un DLR en prueba de lectura, identidad, consentimiento o éxito de autenticación.
• Valide el OTP en el servidor aunque se haya informado una entrega.

Reglas prácticas por escenario

En la primera solicitud, valide y normalice el destino conforme al marco internacional de numeración aplicable, cree la transacción, genere el secreto de corta duración y registre el evento antes de iniciar el envío. El resultado debe asociarse a identificadores de solicitud, código y mensaje sin registrar el secreto en texto claro.

En un reenvío temprano, si existe una solicitud activa y no se ha cumplido el enfriamiento, no genere automáticamente otro código. Devuelva una respuesta genérica que indique la espera aplicable y mantenga la posibilidad de introducir el código actual. Si se permite un reenvío al finalizar el enfriamiento, aplique la política elegida para el código anterior de forma atómica.

Cuando el código haya expirado, cierre la solicitud anterior y cree una nueva solo si los límites y las señales de riesgo lo permiten. Si la plataforma confirma un fallo técnico antes de que el envío haya sido aceptado, puede definirse una excepción de reintento; esa excepción debe quedar trazada y no debe convertirse en un mecanismo ilimitado de generación.

Ante un cambio de canal, no presuponga que SMS es adecuado para todos los casos. El uso del PSTN para autenticación fuera de banda tiene riesgos que deben evaluarse. Considere las señales de riesgo disponibles, como cambios de dispositivo, SIM o portabilidad, y dirija a un autenticador alternativo autorizado cuando la política lo requiera.

• Primera solicitud: crear contexto, registrar, enviar y activar temporizadores.
• Reenvío durante enfriamiento: mantener el código vigente y mostrar el tiempo de espera.
• Código expirado: cerrar el contexto anterior antes de emitir uno nuevo.
• Fallo técnico confirmado: aplicar una excepción limitada, idempotente y auditable.
• Cambio de canal: preservar el contexto de riesgo y no degradar controles de verificación.

DLR pendientes, rechazados o entregados: tratamiento prudente

Un DLR pendiente indica que aún no existe una actualización terminal disponible para esa operación. No es una razón suficiente para emitir de inmediato otro SMS. Mantenga la ventana de enfriamiento y permita que el usuario introduzca el código mientras siga vigente.

Un rechazo o fallo reportado puede justificar una política de reintento controlado si se confirma que el envío no fue aceptado o no avanzó según los criterios internos definidos. Aun así, el reintento debe estar sujeto a límites y a una clave de idempotencia para que los reintentos de red no creen múltiples mensajes.

Si se informa entrega, mantenga la regla de no equivalencia: el sistema puede registrar ese estado para análisis operativo, pero no debe bloquear toda alternativa ni concluir que el usuario ya dispone del código. La autenticación se completa únicamente cuando el verificador acepta el secreto válido devuelto por la persona.

• Pendiente: esperar, conservar la solicitud y no inferir fallo.
• Rechazado: comprobar el significado técnico del evento antes de reintentar.
• Entregado: registrar como señal de transporte, no como lectura ni autenticación.
• Fuera de orden: conservar el evento para diagnóstico sin retroceder el estado interno.
• Duplicado: aceptar el callback de forma idempotente y evitar efectos repetidos.

Controles de abuso sin bloquear a usuarios legítimos

La supresión de reenvíos debe combinarse con límites de solicitud y límites de verificación. Los OTP cortos requieren limitar los intentos fallidos de comprobación para reducir la adivinación en línea. La emisión de un código nuevo no debe restablecer ese contador de fallos.

No base el control solo en una dirección IP. OWASP recomienda asociar los contadores de fallos a la cuenta y usar IP, dispositivo, ubicación, hora y comportamiento como señales complementarias. Para solicitudes OTP, el número de destino, la cuenta, la sesión y el dispositivo pueden aportar contexto distinto; ninguno debe considerarse una prueba de identidad por sí mismo.

Aplique medidas graduales en lugar de una única respuesta binaria. NIST contempla esperas crecientes, detección de bots y evaluación adaptativa como técnicas que pueden complementar la limitación. Revise los falsos positivos: viajes, redes compartidas, dispositivos nuevos, cobertura limitada y necesidades de accesibilidad pueden explicar comportamientos legítimos.

• Límites por cuenta: protegen el flujo de autenticación asociado.
• Límites por número: reducen la presión de envío hacia un destino concreto.
• Límites por sesión y dispositivo: ayudan a detectar repetición automatizada en el mismo contexto.
• IP y otras señales: aportan contexto, pero no deben ser el único criterio.
• Escalado gradual: espera, desafío adicional, alternativa autorizada o revisión, según el riesgo.