¿Cómo genera una app de autenticación TOTP esos códigos de 6 dígitos?
Respuesta breve
TOTP (contraseña de un solo uso basada en tiempo) combina un secreto compartido, establecido en el registro, con la hora actual dividida en ventanas fijas (normalmente 30 segundos). Ejecuta HMAC sobre el contador del paso de tiempo con el secreto, luego trunca el resultado a un código de 6 dígitos. Tanto la app como el servidor tienen el mismo secreto y reloj, así que calculan independientemente el mismo código, sin necesidad de llamada de red. El código rota en cada ventana.
Esta pregunta comprueba si entiendes que los códigos de autenticación se calculan, no se entregan: no hay ningún mensaje en tránsito que interceptar, que es lo que hace a TOTP más fuerte que el SMS.
La configuración
Cuando te registras, el servidor genera un secreto compartido aleatorio y se lo muestra a tu app, normalmente como un código QR (la URI otpauth://). Tanto el servidor como tu app de autenticación tienen ahora el mismo secreto. Nada de ese secreto vuelve a viajar por la red.
Generar un código
TOTP está construido directamente sobre HMAC (es HOTP con un contador basado en el tiempo). La hora Unix actual se divide por un tamaño de paso —normalmente 30 segundos— para producir un valor de contador. La app calcula HMAC(secreto, paso_de_tiempo), luego aplica una truncación dinámica definida para reducir ese resumen a un número de 6 dígitos. Como la entrada es la ventana temporal, el código cambia cada 30 segundos. El servidor, que tiene el mismo secreto y lee el mismo reloj, calcula el código idéntico y compara. Sin ida y vuelta, sin SMS, sin correo, lo que elimina los riesgos de SIM-swap e interceptación que aquejan a la OTP por SMS.
Manejar la deriva de reloj
Los teléfonos y los servidores no tienen relojes perfectamente sincronizados, así que los servidores normalmente aceptan el código de las ventanas temporales adyacentes (un paso antes/después) para tolerar pequeñas derivas, equilibrando la usabilidad con la ventana de adivinación ligeramente mayor.
La limitación
TOTP no es resistente al phishing. Un proxy de phishing en tiempo real puede presentar una página de inicio de sesión falsa, capturar tanto la contraseña como el código de 6 dígitos en vivo, y reproducirlos en el sitio real dentro de la ventana de 30 segundos. Por eso FIDO2/passkeys —que vinculan criptográficamente la credencial al origen legítimo— son el estándar de oro. TOTP sigue siendo mucho mejor que el SMS y un segundo factor sólido para la mayoría de las apps.
Qué buscan los entrevistadores
El cálculo HMAC de secreto-compartido-más-tiempo, «calculado sin conexión, no transmitido», la rotación de 30 segundos y la tolerancia a la deriva de reloj, y la honestidad de que TOTP aún puede ser víctima de phishing en tiempo real mientras que el SMS es aún más débil.
Posibles preguntas de seguimiento
- ¿Por qué TOTP aún puede ser víctima de phishing en tiempo real, y qué lo soluciona?
- ¿Cómo manejan los servidores la deriva de reloj entre la app y el servidor?
- ¿Por qué debe protegerse el secreto compartido en reposo en ambos extremos?