La mayoría de las veces, configurar una app de autenticación es invisible: escaneas un QR, aparecen seis dígitos y se renuevan cada 30 segundos. Esa experiencia fluida existe porque casi todos los servicios y casi todas las apps coinciden en los mismos valores por defecto. Pero una minoría de servicios se aparta deliberadamente de esos valores — emiten códigos de 8 dígitos, usan SHA-256 o SHA-512 en lugar de SHA-1, o renuevan cada 60 segundos en vez de 30. Cuando eso ocurre y tu app no respeta esas decisiones, obtienes el fallo más desconcertante de la autenticación en dos pasos: un código que parece perfectamente válido, se teclea perfectamente y es rechazado una y otra vez. Esta guía explica exactamente qué parámetros pueden cambiar, dónde quedan registrados y cómo confirmarlos para que nunca persigas un error fantasma de nuevo.
Los Valores por Defecto de RFC 6238: SHA-1, 6 Dígitos, 30 Segundos
Las contraseñas de un solo uso basadas en tiempo están definidas por RFC 6238, que se construye directamente sobre el algoritmo HOTP de RFC 4226. TOTP es simplemente HOTP con el contador móvil sustituido por el número de pasos de tiempo fijos transcurridos desde la época Unix. Tres parámetros gobiernan la salida, y el estándar define un valor por defecto para cada uno:
- Algoritmo de hash: el HMAC subyacente usa SHA-1 por defecto. RFC 6238 también permite explícitamente las variantes SHA-256 y SHA-512.
- Dígitos: RFC 4226 define un paso de truncamiento dinámico que produce un código de la longitud elegida. Seis dígitos es el valor por defecto casi universal; el estándar permite valores de 6 hasta 8.
- Paso de tiempo (período): RFC 6238 recomienda un tamaño de paso de tiempo por defecto de 30 segundos. Cualquier valor es técnicamente posible, pero 30 es la norma interoperable.
Si tanto el servidor como tu app asumen estos tres valores por defecto, nunca tienen que comunicárselos — el acuerdo es implícito y los códigos coinciden. El problema empieza en el momento en que un lado cambia un valor en silencio y asume que el otro lo seguirá. Para entender cómo se supone que deben mantenerse sincronizados, ayuda leer el artículo pilar sobre cómo funciona la autenticación TOTP, que recorre paso a paso la matemática del HMAC y el truncamiento.
Dónde Viven los Parámetros: la URI otpauth://
Cuando escaneas un QR de alta, no estás escaneando solo el secreto. El QR codifica una única URI en el Key URI Format documentado originalmente por Google Authenticator. Una cadena de alta típica tiene este aspecto:
otpauth://totp/Example:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=Example&algorithm=SHA256&digits=8&period=60
Cada parámetro no predeterminado queda escrito ahí mismo en la cadena de consulta. El parámetro algorithm lleva SHA1, SHA256 o SHA512; digits lleva de 6 a 8; period lleva el paso de tiempo en segundos. Cuando estos parámetros están ausentes, se espera que la app recurra a los valores por defecto (SHA1, 6, 30). Cuando están presentes, son el servicio diciéndole a toda app conforme exactamente cómo calcular el código. Esta es la verdad de fondo — no el texto comercial de la página de configuración, ni un artículo de soporte, sino los parámetros literales incrustados en el QR que escaneaste.
Por Qué un Servicio se Apartaría de los Valores por Defecto
Apartarse es poco común, pero las razones son legítimas:
- Cumplimiento y política interna. Algunas organizaciones estandarizan SHA-256 en todas sus primitivas criptográficas y extienden esa regla a su stack de OTP, aunque SHA-1 tal como se usa dentro de HMAC-OTP no se considera roto para este propósito.
- Códigos más largos para sistemas de mayor valor. Ocho dígitos amplían el espacio de adivinación por intento, algo que algunos sistemas bancarios y corporativos prefieren como medida de defensa en profundidad junto al rate limiting.
- Compatibilidad con tokens hardware. Un servicio puede ya emitir tokens OTP físicos configurados para 8 dígitos o una ventana de 60 segundos, y su alta por software debe coincidir exactamente con esos tokens.
- Menor presión de sincronización de reloj. Un período de 60 segundos tolera un mayor desfase de reloj entre el servidor y el dispositivo del usuario, lo que puede reducir tickets de soporte en poblaciones con relojes mal sincronizados.
Ninguna de estas decisiones es errónea. El problema nunca es la elección en sí — es si la elección sobrevive al viaje desde el QR hasta tu app de autenticación.
La Trampa de Interoperabilidad: Apps que Ignoran los Parámetros
Aquí está el modo de fallo que le cuesta horas a la gente. La propia documentación del Key URI Format lleva una advertencia bien conocida: algunas implementaciones de autenticador ignoran por completo los parámetros algorithm, digits y period y siempre asumen SHA-1, 6 dígitos y 30 segundos. Históricamente esto incluyó apps muy usadas. Una app que se comporta así escaneará una URI con algorithm=SHA256&digits=8&period=60 sin ningún error, guardará el secreto y luego generará alegremente un código de 6 dígitos SHA-1 en un ciclo de 30 segundos — el código equivocado, producido con total confianza.
Esto es exasperante precisamente porque nada parece roto. No hay mensaje de error en el alta. La app muestra un código y una cuenta atrás. Lo tecleas con cuidado. El servidor lo rechaza, porque el servidor está calculando un código de 8 dígitos SHA-256 y comparándolo con tu respuesta de 6 dígitos SHA-1. Asumes que te equivocaste al teclear, o que tu reloj va mal, y vuelves a intentarlo — con el mismo fallo garantizado. El desajuste es silencioso por construcción, que es exactamente por lo que sobrevive a tantos intentos de solución. Si estás atrapado en este bucle, el artículo dedicado sobre por qué mi código 2FA no funciona cubre la lista de comprobación completa, pero los parámetros no predeterminados son una de las causas más difíciles de detectar precisamente porque la app no da ninguna pista de que los descartó.
Cómo Confirmar Qué Parámetros Usa un Servicio
Como no puedes confiar en que una app te diga qué guardó, confirma los parámetros en el origen — dentro del propio QR. El método fiable es decodificar el QR de alta a su URI otpauth:// cruda y leer la cadena de consulta:
- Decodifica el QR a texto. En lugar de escanear el QR con tu teléfono, captúralo como imagen y decodifícalo para revelar la URI subyacente. Nuestro generador TOTP puede leer una URI
otpauth://para que veas exactamente quéalgorithm,digitsyperiodincrustó el servicio. - Busca los tres parámetros de consulta. Si ves
algorithm=SHA256,digits=8operiod=60, el servicio se ha apartado y toda app que uses debe respetar esos valores. Si esos parámetros están ausentes, el servicio usa los valores por defecto y cualquier app conforme funcionará. - Reproduce el código con la configuración coincidente. Introduce el mismo secreto y los mismos parámetros en una herramienta cuyas opciones avanzadas te permitan elegir explícitamente el algoritmo, el número de dígitos y el período. Si el código de esa herramienta coincide con lo que el servidor espera, has confirmado los parámetros; si tu app del teléfono muestra un código diferente, tu app del teléfono es el componente que los ignora.
Esto convierte un desajuste invisible en una comprobación de dos minutos. El QR es el contrato; decodificarlo te dice los términos.
SHA-256 No Es una Palanca de Seguridad que Puedas Accionar
Un malentendido común es que cambiar una cuenta existente de SHA-1 a SHA-256 hace tu inicio de sesión más seguro, y que puedes hacerlo tú mismo en una app mejor. No puedes, y no ayudaría. El algoritmo, el número de dígitos y el período son un acuerdo compartido: el valor que el servidor usa para generar y verificar el código debe ser idéntico al que tu app usa para producirlo. Si el servidor verifica con SHA-1 y tu app produce SHA-256, los códigos nunca coinciden y simplemente te bloqueas fuera. No hay actualización unilateral — solo negociada, y esa negociación ocurre en el momento del alta mediante la URI, no a través de un ajuste que activas después.
También conviene ser claro sobre lo que realmente está en juego en seguridad. Los ataques de colisión de SHA-1 que retiraron a SHA-1 de los certificados no se traducen en una ruptura práctica de HMAC-SHA-1 tal como se usa en TOTP, que se apoya en las propiedades de preimagen y de MAC con clave de la construcción, no en la resistencia a colisiones. Así que SHA-256 en un contexto TOTP es sobre todo una cuestión de interoperabilidad y política organizativa, no un salto significativo en la fortaleza de tus códigos de un solo uso. Elegirlo porque "suena más fuerte" solo crea oportunidades para el error de desajuste silencioso descrito arriba.
Dígitos: 6, 7 u 8
El número de dígitos cambia el tamaño del espacio de códigos por intento. Seis dígitos dan un millón de posibilidades; ocho dan cien millones. Combinados con el rate limiting del lado del servidor — que limita cuántos intentos consigue un atacante antes de que la cuenta se bloquee — seis dígitos ya son suficientes para la mayoría de modelos de amenaza de consumidor, y por eso el valor por defecto ha aguantado más de una década. Ocho dígitos son una elección razonable de tirantes y cinturón para sistemas de alto valor, pero solo compran protección real cuando el rate limiting es débil o inexistente. La conclusión práctica no cambia: sea cual sea el número de dígitos, hay que decírselo a tu app, y la única fuente fiable de esa instrucción es el parámetro digits de la URI.
Período: 30 Frente a 60 Segundos
El período fija cuánto tiempo cada código sigue siendo válido antes de que se calcule el siguiente. Treinta segundos es el valor por defecto interoperable; sesenta es la desviación más común. Un período más largo da al usuario más tiempo para teclear y tolera un mayor desfase de reloj entre el dispositivo y el servidor, a costa de una ventana algo más larga en la que un código capturado sigue siendo usable. Los servidores suelen aceptar también un código del paso inmediatamente anterior y siguiente, para absorber pequeñas diferencias de reloj — pero esa ventana de gracia no rescata a una app que está ejecutando un período equivocado por completo. Si la URI dice period=60 y tu app asume 30, ambos están calculando códigos para pasos de tiempo distintos y casi nunca coincidirán.
Igualar los Parámetros en Nuestro Generador
Nuestro generador TOTP expone los tres parámetros como ajustes avanzados precisamente para que puedas reproducir la configuración de cualquier servicio. Pega el secreto compartido, despliega las opciones avanzadas y ajusta el algoritmo (SHA-1, SHA-256 o SHA-512), el número de dígitos (6 a 8) y el período (en segundos) para que coincidan con lo que decodificaste del QR. Si prefieres no leer la cadena de consulta a mano, pega la URI otpauth:// completa y deja que la herramienta analice los parámetros por ti. El código que produce la herramienta coincidirá con el servidor exactamente cuando la configuración coincida — y divergirá de forma diagnóstica cuando no, que es lo que la hace útil para confirmar si tu app del teléfono es la culpable. Todo se ejecuta localmente en tu navegador; el secreto nunca se transmite.
Una Regla Sencilla para Recordar
Cuando TOTP "simplemente funciona", los valores por defecto estaban en juego en ambos lados. Cuando se niega tercamente a funcionar pese a un código bien tecleado y un reloj sincronizado, sospecha de un parámetro no predeterminado que algún componente descartó en silencio. Decodifica el QR, lee algorithm, digits y period, y haz que toda app los respete. La especificación da a los servicios la libertad de apartarse; recae en las apps — y en ti, cuando una app se porta mal — llevar esas desviaciones fielmente desde el QR hasta los seis, siete u ocho dígitos que finalmente tecleas.