Introduce un secreto válido para ver el código.
Comprueba un código como lo haría el servidor: se acepta el actual y hasta 2 pasos antes o después, para tolerar relojes desfasados.
Cómo funciona
TOTP (Time-based One-Time Password, RFC 6238) es el algoritmo que hay detrás de los códigos de seis dígitos de Google Authenticator, Microsoft Authenticator, Authy o 1Password. El servicio y tu móvil comparten un secreto; cada 30 segundos ambos calculan un HMAC del secreto con la hora actual dividida en pasos, lo recortan a seis dígitos y comparan el resultado. Como nadie transmite el código hasta que lo escribes, funciona aunque el móvil no tenga conexión.
HOTP (RFC 4226) es el algoritmo base: en lugar de la hora usa un contador que avanza cada vez que se pide un código. TOTP es HOTP con el contador sustituido por el número de periodos transcurridos desde 1970. El secreto se escribe en Base32 y viaja dentro de un URI otpauth:// que se muestra como código QR al activar la verificación en dos pasos.
La herramienta genera secretos con el generador criptográfico del navegador, calcula el código actual, el anterior y el siguiente, construye el URI y su QR, lee un URI existente y verifica un código con la misma tolerancia de reloj que usan los servidores. El secreto nunca sale de tu navegador ni se incluye en el enlace para compartir.
Ejemplos
GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 59 s94287082Vector de prueba de la RFC 6238. El secreto es el texto ASCII 12345678901234567890 codificado en Base32; a los 59 segundos de la época Unix el paso es 1 y el código de ocho dígitos tiene que ser exactamente este.GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 1111111109 s07081804Otro vector de la RFC 6238, útil para comprobar que tu implementación no pierde los ceros a la izquierda: el código es un número de dígitos fijos, no un entero.HOTP · GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · contador 0755224Primer vector de la RFC 4226 con seis dígitos. Con el contador en 1 el código pasa a ser 287082.otpauth://totp/Ejemplo:ana%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=EjemploTOTP · SHA1 · 6 · 30 sEl formato Key URI que definió Google Authenticator y que adoptaron las demás apps. Si faltan algorithm, digits y period se asumen SHA1, 6 y 30, así que la mayoría de los QR solo llevan el secreto y el emisor.Casos de uso
- Probar la activación de 2FA de tu aplicación: generar un secreto, escanear el QR con el móvil y comprobar que el servidor acepta el mismo código que muestra la app.
- Depurar por qué un servidor rechaza códigos válidos: ver si coinciden con el paso anterior o el siguiente revela un reloj desfasado.
- Validar una implementación propia de TOTP o HOTP con los vectores de prueba de las RFC 6238 y 4226.
- Leer un URI otpauth:// exportado de otra app para revisar qué algoritmo, cuántos dígitos y qué periodo usa la cuenta.
- Cargar en una segunda app o en un gestor de contraseñas una cuenta de prueba cuyo secreto ya tienes en Base32.
Preguntas frecuentes
¿Por qué el servidor rechaza un código que la app muestra como válido?
Casi siempre es el reloj. TOTP depende de que el móvil y el servidor estén de acuerdo en la hora: con 30 segundos de diferencia ya calculan pasos distintos. Por eso los servidores aceptan uno o dos pasos hacia cada lado. Si el código coincide con el paso anterior o el siguiente, sincroniza la hora del servidor con NTP y activa la hora automática del móvil.
¿Es seguro generar aquí el secreto de una cuenta real?
El secreto se genera con crypto.getRandomValues y no sale de tu navegador, pero en producción debe generarlo y guardarlo el servidor que va a verificar los códigos. Esta herramienta sirve para probar y depurar. Trata cualquier secreto real como una contraseña: quien lo tenga puede generar tus códigos para siempre.
¿Conviene usar SHA-256, 8 dígitos o 60 segundos?
En teoría son más robustos, pero varias apps, entre ellas algunas versiones de Google Authenticator, ignoran esos parámetros y calculan siempre SHA-1 con 6 dígitos cada 30 segundos, con lo que el usuario ve códigos que el servidor rechaza. SHA-1 sigue siendo seguro como HMAC. Por compatibilidad, casi todos los servicios usan los valores por defecto.
¿Qué longitud debe tener el secreto?
La RFC 4226 exige al menos 128 bits y recomienda 160, que en Base32 son 32 caracteres. Muchos servicios usan 80 bits (16 caracteres) y las apps los aceptan igualmente. Esta herramienta genera 160 bits.
¿TOTP protege contra el phishing?
No del todo. Es mucho mejor que el SMS, que se puede interceptar o robar con un duplicado de SIM, pero un sitio falso puede pedirte el código y usarlo en el real dentro de los mismos 30 segundos. Las llaves de seguridad FIDO2 y las passkeys están ligadas al dominio y resisten ese ataque.
¿Qué pasa si pierdo el móvil?
Sin el secreto no hay forma de calcular los códigos. Por eso los servicios entregan códigos de recuperación al activar 2FA: guárdalos fuera del móvil. Algunas apps permiten hacer copias de seguridad cifradas de las cuentas en la nube o exportarlas como QR para pasarlas a otro dispositivo.