Entrega y fraude del OTP: qué prueba

Qué prueba un OTP

Un OTP responde a una pregunta: ¿la persona que tengo delante puede recibir un mensaje en este número ahora mismo? Eso sirve para recuperar una cuenta y para iniciar sesión, porque ata la sesión a algo que el usuario controla. No es un documento de identidad. El número puede reciclarse, pasar a otra SIM, desviarse o ser leído por otra persona del hogar.

La distinción importa en el diseño. Si la acción es de bajo valor, un OTP es proporcionado. Si mueve dinero, cambia una contraseña o añade un beneficiario, combine el código con una segunda comprobación: una espera, una confirmación en una sesión existente, una llamada a un canal conocido o una revisión manual. El código es un factor, no toda la decisión.

Dónde se filtra un OTP

Un cambio de SIM traslada el número a una tarjeta nueva. El atacante convence a una tienda o a una línea de soporte de que es el titular, y el siguiente código va a la SIM nueva. El reciclaje de números produce el mismo efecto sin atacante: la operadora reasigna un número inactivo y el nuevo titular recibe un código pensado para la cuenta anterior. Ambos son motivos para comprobar si un número se portó o se reasignó hace poco.

El desvío y el buzón de voz a texto mandan el mensaje a otra bandeja. El phishing copia el formulario y recoge el código directamente, así que la red nunca ve un ataque. La interceptación en el camino de red es más rara y queda fuera del control de la aplicación; la respuesta práctica es un segundo factor, no un código más largo. Consulte la entrada de OTP del glosario para las definiciones.

Controles que ayudan

Limite la frecuencia con que un número, una dirección IP y un dispositivo pueden pedir un código. Use una validez corta, un solo uso por código y ate el código a la sesión que lo pidió. Registre el remitente y mantenga el contenido sobrio: un código que parece marketing puede ser filtrado, y un código filtrado genera un ticket de soporte, no un inicio de sesión.

Compruebe el número antes de confiar en él. Un número que no puede recibir SMS, que se portó hace poco o que tiene historial de restablecimientos merece un paso adicional. Para acciones de alto valor, exija una sesión existente o un segundo canal. Registre la petición, el envío, el acuse y la introducción del código como eventos separados, para distinguir un problema de entrega de un problema del usuario.

Diseñe el código con el mismo cuidado. Genérelo con una fuente criptográfica, guarde un hash, hágalo caducar en minutos, permita un solo uso correcto y limite los intentos por código y por sesión. No revele si el número existe. Cree el registro de la cuenta antes del envío, para que un reintento no abra una cuenta que nunca se completa.

Mida el flujo, no el envío

Un envío que devuelve un message ID no es un código entregado. Un código entregado no es un inicio de sesión completado. Construya el embudo con los eventos que controla: envío, acuse, introducción del código, éxito. Compárelo con la visión del proveedor. Una diferencia entre su tasa de entrega y la suya puede ser un acuse que nunca llegó a su manejador, no un mensaje que nunca llegó al teléfono.

Revise el flujo cuando se mueve una métrica. Una caída de finalización con entrega estable apunta al formulario, a la caducidad del código o al remitente. Una caída de entrega con envío estable apunta a la ruta, al número o al filtro de contenido. Una subida de reenvíos apunta al tiempo de entrega. Corrija el paso que nombran los datos, no el más fácil de cambiar.

Fije una fecha de revisión para todo el flujo. Los números cambian de manos, las rutas cambian y las plantillas envejecen. Un flujo que funcionaba al lanzamiento puede fallar en silencio seis meses después, con el mismo código y el mismo proveedor.