Probar una integración 2FA
Estás desarrollando la activación en dos pasos: genera un secreto, importa la URI en tu app de autenticación y comprueba que tu servidor acepta los mismos códigos.
Introduce o genera un secreto Base32 de 160 bits, elige SHA-1, SHA-256 o SHA-512, 6 u 8 dígitos y el periodo: el código TOTP actual se actualiza con una cuenta atrás, la URI otpauth:// queda lista para una app de autenticación y puedes verificar un código con una tolerancia de un periodo.
La clave compartida que aparece bajo el código QR de activación (letras A-Z y cifras 2-7).
Codifícalo en un código QR para Google Authenticator, Microsoft Authenticator, Aegis o 1Password.
Esta herramienta calcula los códigos de un solo uso TOTP, los que muestran Google Authenticator, Microsoft Authenticator o 1Password, a partir de un secreto Base32. Ayuda a los desarrolladores que integran la autenticación en dos pasos a probar su implementación, y a los administradores a comprobar un secreto o preparar una URI de registro.
TOTP (RFC 6238) es la variante temporal de HOTP (RFC 4226). Se calcula un contador T = floor(hora Unix / periodo), 30 segundos por defecto, y después HMAC(secreto, T) con SHA-1, SHA-256 o SHA-512. Un «truncado dinámico» extrae 4 bytes del HMAC a partir de un desplazamiento dado por sus 4 últimos bits, y el resultado módulo 10^6 (o 10^8) es el código. Ejemplo de la RFC: con el secreto ASCII `12345678901234567890` (Base32 `GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ`), SHA-1 y el instante 59 s, el código de 8 dígitos es 94287082.
La herramienta decodifica el secreto Base32 (o genera uno de 160 bits, 32 caracteres, con crypto.getRandomValues), calcula el código actual con Web Crypto y lo actualiza con una cuenta atrás hasta el siguiente periodo. Construye la URI `otpauth://totp/Emisor:cuenta?secret=…&issuer=Emisor&algorithm=SHA1&digits=6&period=30` que importan las apps, normalmente mediante un código QR. Para verificar, compara el código introducido con los del periodo anterior, actual y siguiente, lo que absorbe un pequeño desfase de reloj.
Pega un secreto Base32 o genera uno de 160 bits y elige el algoritmo (SHA-1, SHA-256, SHA-512), el número de dígitos (6 u 8) y el periodo (30 s por defecto).
El código actual aparece con su cuenta atrás; indica el emisor y el nombre de la cuenta para obtener la URI otpauth:// que importarás en una app.
Escribe un código recibido: la herramienta te dice si coincide con el periodo actual, el anterior o el siguiente.
Estás desarrollando la activación en dos pasos: genera un secreto, importa la URI en tu app de autenticación y comprueba que tu servidor acepta los mismos códigos.
Compara el código esperado para un secreto con el de la app del usuario para distinguir un secreto erróneo, un algoritmo distinto o un reloj desfasado.
Construye la URI otpauth:// con el emisor y el nombre de cuenta correctos y conviértela en un código QR para el equipo que debe registrar la cuenta.
La causa más habitual es un reloj desfasado en el móvil o en el servidor: bastan unas decenas de segundos para cambiar de periodo. Después vienen un secreto mal copiado y un algoritmo, número de dígitos o periodo distintos de los que espera el servicio. Activa la hora automática y compara el código de esta herramienta con el de la app.
HOTP (RFC 4226) calcula el código a partir de un contador que aumenta en cada uso y que debe mantenerse sincronizado entre cliente y servidor. TOTP (RFC 6238) sustituye ese contador por el tiempo dividido en periodos de 30 segundos, así que el código caduca solo. Casi todas las apps 2FA de consumo usan TOTP.
El servicio la muestra al activar la 2FA, debajo del código QR, a menudo como «clave de configuración» o «introducir el código manualmente». El propio QR contiene una URI otpauth:// cuyo parámetro secret es esa clave en Base32. Una vez terminada la activación, la mayoría de servicios no vuelve a mostrarla.
No está garantizado: la documentación histórica del formato de URI indica que Google Authenticator ignoraba algorithm, digits y period y generaba códigos SHA-1 de 6 dígitos que entonces no coinciden. Apps como 1Password o Authy aceptan SHA-256 y SHA-512. Para un servicio público, SHA-1 de 6 dígitos sigue siendo la opción compatible, y es segura dentro de la construcción HMAC.
Un código corresponde a un periodo, 30 segundos por defecto. Muchos servidores, igual que esta herramienta al verificar, aceptan también el periodo anterior y el siguiente para compensar la latencia y el desfase de reloj, lo que da una ventana efectiva de unos 90 segundos.
El secreto genera todos tus códigos futuros: quien lo tenga dispone de tu segundo factor. Aquí el cálculo se hace solo en tu navegador con Web Crypto y no se transmite nada. Aun así, evita pegar el secreto de una cuenta de producción real en un dispositivo compartido; mejor usa un secreto de prueba.
Herramientas relacionadas
Herramientas similares o complementarias a esta.
Genera tokens aleatorios seguros de 8 a 256 bytes en hexadecimal, Base64 o Base64URL, con prefijo opcional.
Calcula un HMAC SHA-1, SHA-256, SHA-384 o SHA-512 en hex o Base64 y verifica una firma de webhook.
Genera contraseñas seguras y aleatorias de 8 a 128 caracteres, con la entropía indicada.
Aprende cuándo utilizar cifrado, hashing, HMAC o PBKDF2 para confidencialidad, integridad, autenticación y contraseñas.
Aprende a implantar una CSP de forma progresiva, sus directivas principales, Report-Only, nonces y errores frecuentes.