Ingresá un secreto válido para ver el código.
Comprobá 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 detrás de los códigos de seis dígitos de Google Authenticator, Microsoft Authenticator, Authy o 1Password. El servicio y tu teléfono comparten un secreto; cada 30 segundos los dos 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 escribís, sirve aunque el teléfono 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 reemplazado por el número de períodos 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, arma 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 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 sólo 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 teléfono 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 contra 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é período usa la cuenta.
- Cargar en una segunda app o en un gestor de contraseñas una cuenta de prueba cuyo secreto ya tenés 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 teléfono 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, sincronizá la hora del servidor con NTP y activá la hora automática del teléfono.
¿Es seguro generar acá el secreto de una cuenta real?
El secreto se genera con crypto.getRandomValues y no sale de tu navegador, pero en producción lo tiene que generar y guardar el servidor que va a verificar los códigos. Esta herramienta sirve para probar y depurar. Tratá 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 fuertes, pero varias apps, entre ellas 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é largo 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 igual. 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 cambio 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 teléfono?
Sin el secreto no hay forma de calcular los códigos. Por eso los servicios entregan códigos de recuperación al activar 2FA: guardalos fuera del teléfono. Algunas apps permiten respaldar las cuentas cifradas en la nube o exportarlas como QR para pasarlas a otro equipo.