API de autenticación en dos pasos

La autenticación en dos pasos pide una segunda prueba independiente junto a la contraseña: algo que sabe más algo que tiene. La independencia es todo el asunto. Una base de contraseñas filtrada vale mucho menos cuando por sí sola no abre ninguna cuenta.

El segundo factor solo ayuda en la medida en que sea realmente independiente. Un código enviado a una dirección protegida por la misma contraseña no es un segundo factor; una prueba ligada a un dispositivo físico sí lo es.

El SMS es el segundo factor más desplegado y el más débil de los que aún se usan habitualmente. Los códigos pueden redirigirse con un SIM swap, obtenerse mediante una página convincente que simplemente pide leerlos en voz alta, y retrasarse o perderse por el enrutamiento del operador. Cada envío además cuesta dinero, lo que convierte el inicio de sesión en un lugar donde un atacante puede gastar su presupuesto.

Nada de esto hace inútil la 2FA por SMS — es enormemente mejor que no tener segundo factor. Sí significa que, si elige hoy, hay pocas razones para elegirla como opción por defecto.

Enviar el desafío por WhatsApp saca al operador del camino: la entrega va por internet, el mensaje está cifrado de extremo a extremo y no hay coste por SMS. Además llega a una aplicación que el usuario ya tiene abierta en la mayoría de los mercados.

Por sí solo, sin embargo, esto arregla la entrega y el coste, no la debilidad de fondo. Un código sigue siendo un código, y a un usuario que puede leer uno se le puede convencer de repetírselo a un atacante.

El Reverse OTP cambia qué es el segundo factor. En lugar de enviar un secreto al dispositivo y pedir al usuario que lo transmita, pide al dispositivo que envíe un mensaje. El usuario toca un enlace y pulsa enviar; el servidor asocia el mensaje entrante a la sesión de inicio de sesión pendiente.

Eso elimina por completo el objeto susceptible de phishing. No hay ningún código en pantalla que leer en voz alta, nada en tránsito que interceptar y nada que un SIM swap pueda redirigir — la prueba viene de una cuenta de WhatsApp ligada al teléfono, no de un número que un operador puede reasignar.

Las llamadas son las mismas dos del registro. Cuando un inicio de sesión requiera un segundo factor, abra una sesión con POST /start-verification usando un identificador ligado a ese intento de inicio de sesión y presente el enlace profundo devuelto. Mantenga la sesión abierta en el servidor y complete el inicio de sesión solo cuando GET /check-verification-status informe verified.

Dos reglas mantienen esto sólido. Ligue la sesión de verificación al intento de inicio de sesión, no al usuario, para que una sesión completada nunca pueda autorizar otra distinta. Y compare el número que devuelve la API con el número guardado en la cuenta — un número verificado que no es el de ese usuario es un segundo factor fallido, no superado.

Ofrezca SMS como respaldo donde WhatsApp no esté disponible, sobre la misma sesión, para que un usuario de un mercado de baja adopción no quede bloqueado. Más allá de eso, planifique el caso en que el propio teléfono desaparezca: un segundo factor sin vía de recuperación es una incidencia en preparación, y los usuarios que pierden el acceso suelen perder la cuenta con él.

Los códigos de recuperación emitidos al registrar el factor son la respuesta habitual. Elija lo que elija, decídalo antes del lanzamiento — una recuperación diseñada durante un incidente siempre es peor.

Para productos de consumo, los segundos factores por teléfono tienen una ventaja decisiva: los usuarios ya tienen el dispositivo y no necesitan registrar nada. Por eso su adopción es muy superior a la de las aplicaciones de autenticación o las llaves físicas.

Para cuentas que protegen un valor serio — acceso administrativo, control financiero, infraestructura — una llave de seguridad física sigue siendo la opción más fuerte, y ambas se combinan bien. Use la verificación por teléfono donde importe la cobertura y las llaves donde importe la profundidad.