Por que fallan os códigos TOTP cando o reloxo do dispositivo se desvía

Os códigos dun só uso poden ser perfectamente correctos no seu teléfono e ser rexeitados polo servidor no mesmo segundo. Ambos os lados calculan a mesma función a partir dun segredo compartido e do paso de tempo actual, así que unha discrepancia sobre a hora produce unha discrepancia sobre o código. Iso converte a deriva do reloxo nunha falla relevante para a seguridade e non nunha simple molestia.

Aquí importan dous reloxos, e corrixir o visible é a parte que a xente fai primeiro. O que adoita necesitar atención é o outro.

O código é unha función do tempo, non un contrasinal

TOTP toma o segredo compartido e un contador derivado da hora actual, pasa ambos por un hash con clave e trunca o resultado nunha cadea decimal curta, como se especifica en RFC 6238. O contador avanza en cada paso de tempo, convencionalmente trinta segundos, así que o mesmo segredo produce un valor novo cando cambia o paso. O verificador recalcula o valor esperado para o paso actual e compárao, o que esixe o mesmo segredo e a mesma idea de agora. Un contrasinal segue sendo reutilizable ata que se cambia, mentres que este valor caduca nun límite que o cliente non pode ver.

Por iso un código funciona e o seguinte falla momentos despois. Tamén explica por que copiar un código dunha mensaxe de chat é un hábito tan pouco fiable.

Dous reloxos teñen que coincidir, non un

O material de rexistro é o primeiro compartido, e o tempo é o segundo. Se o segredo é correcto mentres os reloxos difiren máis que a ventá tolerada, cada valor xerado cae no paso equivocado e rexéitase. Se os reloxos coinciden mentres o segredo é incorrecto, cada valor tamén se rexeita, e ambas as fallas parecen idénticas desde a pantalla de inicio de sesión. Sepáralas significa comprobar a entrada da conta e o tempo de forma independente, nesa orde.

O reloxo do verificador merece o mesmo escrutinio que o do dispositivo. Un servidor cuxa fonte de tempo está avariada rexeita os códigos correctos de todos os usuarios á vez, e os informes describirán unha interrupción repentina en lugar dunha deriva. Ese patrón merece recoñecerse, porque a súa corrección pertence ao servidor e non a cen teléfonos.

Que custa ampliar a ventá

As implementacións poden aceptar un código dun paso adxacente para absorber diferenzas pequenas, e esa tolerancia é unha decisión de deseño, non un axuste gratuíto. Cada paso adicional multiplica o número de valores válidos en calquera momento, que é exactamente o que prefire un atacante que adiviña. A regra de repetición importa polo mesmo motivo, xa que un código aceptado dúas veces é un código que se filtrou de forma útil. Un administrador que amplía a ventá para silenciar as queixas troca unha propiedade real por unha mellora cosmética.

Corrixir o reloxo é a reparación, mentres que ampliar a ventá é un sedante. O primeiro elimina a causa e o segundo agácha.

Comprobe ambos os reloxos antes de tentalo de novo

Lea a hora no dispositivo e no servidor, e compare os desfases en lugar das horas locais mostradas. Os comandos seguintes mostran o estado de sincronización e o instante UTC en bruto nun host ou servidor Linux. Execúteos nos dous extremos antes de cambiar calquera axuste de autenticación.

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

Un desfase medido en segundos é inofensivo, un medido en minutos explica un rexeitamento, e un sistema que non informa de ningunha fonte de sincronización é candidato a ambas as cousas. Compare as dúas marcas de tempo UTC directamente, xa que a hora local inclúe unha zona horaria que o algoritmo nunca ve. Se os desfases son pequenos e os códigos seguen fallando, deixe de axustar reloxos e examine a entrada de rexistro. Os intentos repetidos contra unha conta bloqueada fan máis difícil observar a falla orixinal.

Rexiste a hora do rexeitamento, o desfase e o texto do erro, e deixe o segredo compartido fóra diso. O soporte pode traballar cos tres primeiros e nunca debería ver o cuarto.