Por qué fallan los códigos TOTP cuando el reloj del dispositivo se desvía

Los códigos de un solo uso pueden ser perfectamente correctos en su teléfono y ser rechazados por el servidor en el mismo segundo. Ambos lados calculan la misma función a partir de un secreto compartido y del paso de tiempo actual, así que una discrepancia sobre la hora produce una discrepancia sobre el código. Eso convierte la deriva del reloj en una falla relevante para la seguridad y no en una simple molestia.

Aquí importan dos relojes, y corregir el visible es la parte que la gente hace primero. El que suele necesitar atención es el otro.

El código es una función del tiempo, no una contraseña

TOTP toma el secreto compartido y un contador derivado de la hora actual, pasa ambos por un hash con clave y trunca el resultado a una cadena decimal corta, como se especifica en RFC 6238. El contador avanza en cada paso de tiempo, convencionalmente treinta segundos, así que el mismo secreto produce un valor nuevo cuando cambia el paso. El verificador recalcula el valor esperado para el paso actual y lo compara, lo que exige el mismo secreto y la misma idea de ahora. Una contraseña sigue siendo reutilizable hasta que se cambia, mientras que este valor caduca en un límite que el cliente no puede ver.

Por eso un código funciona y el siguiente falla momentos después. También explica por qué copiar un código de un mensaje de chat es un hábito tan poco fiable.

Dos relojes tienen que coincidir, no uno

El material de registro es lo primero compartido, y el tiempo es lo segundo. Si el secreto es correcto mientras los relojes difieren más que la ventana tolerada, cada valor generado cae en el paso equivocado y se rechaza. Si los relojes coinciden mientras el secreto es incorrecto, cada valor también se rechaza, y ambos fallos se ven idénticos desde la pantalla de inicio de sesión. Separarlos significa comprobar la entrada de la cuenta y el tiempo de forma independiente, en ese orden.

El reloj del verificador merece el mismo escrutinio que el del dispositivo. Un servidor cuya fuente de tiempo está averiada rechaza los códigos correctos de todos los usuarios a la vez, y los informes describirán una interrupción repentina en lugar de una deriva. Ese patrón merece reconocerse, porque su corrección corresponde al servidor y no a cien teléfonos.

Qué cuesta ampliar la ventana

Las implementaciones pueden aceptar un código de un paso adyacente para absorber diferencias pequeñas, y esa tolerancia es una decisión de diseño, no un ajuste gratuito. Cada paso adicional multiplica el número de valores válidos en cualquier momento, que es exactamente lo que prefiere un atacante que adivina. La regla de repetición importa por el mismo motivo, ya que un código aceptado dos veces es un código que se filtró de forma útil. Un administrador que amplía la ventana para silenciar las quejas cambia una propiedad real por una mejora cosmética.

Corregir el reloj es la reparación, mientras que ampliar la ventana es un sedante. Lo primero elimina la causa y lo segundo la oculta.

Compruebe ambos relojes antes de reintentar

Lea la hora en el dispositivo y en el servidor, y compare los desfases en lugar de las horas locales mostradas. Los comandos siguientes muestran el estado de sincronización y el instante UTC en bruto en un host o servidor Linux. Ejecútelos en ambos extremos antes de cambiar cualquier ajuste de autenticación.

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

Un desfase medido en segundos es inofensivo, uno medido en minutos explica un rechazo, y un sistema que no informa de ninguna fuente de sincronización es candidato a ambas cosas. Compare las dos marcas de tiempo UTC directamente, ya que la hora local incluye una zona horaria que el algoritmo nunca ve. Si los desfases son pequeños y los códigos siguen fallando, deje de ajustar relojes y examine la entrada de registro. Los intentos repetidos contra una cuenta bloqueada hacen más difícil observar la falla original.

Registre la hora del rechazo, el desfase y el texto del error, y deje el secreto compartido fuera de ello. El soporte puede trabajar con los tres primeros y nunca debería ver el cuarto.