Hvorfor TOTP-koder fejler, når enhedens ur driver

Engangskoder kan være fuldstændig korrekte på din telefon og alligevel afvises af serveren i samme sekund. Begge sider beregner den samme funktion ud fra en delt hemmelighed og det aktuelle tidstrin, så uenighed om tiden giver uenighed om koden. Det gør urdrift til en sikkerhedsrelevant fejl og ikke bare en irritation.

To ure har betydning her, og at rette det synlige er det, folk gør først. Det, der normalt har brug for opmærksomhed, er det andet.

Koden er en funktion af tid, ikke en adgangskode

TOTP tager den delte hemmelighed og en tæller udledt af den aktuelle tid, kører begge gennem en hash med nøgle og afkorter resultatet til en kort decimalstreng, som angivet i RFC 6238. Tælleren rykker frem ved hvert tidstrin, typisk tredive sekunder, så den samme hemmelighed giver en ny værdi, når trinnet skifter. Verifikatoren genberegner den forventede værdi for det aktuelle trin og sammenligner, hvilket kræver den samme hemmelighed og den samme opfattelse af nu. En adgangskode forbliver genbrugelig, indtil den ændres, mens denne værdi udløber på en grænse, som klienten ikke kan se.

Derfor virker den ene kode, og den næste fejler få øjeblikke senere. Det forklarer også, hvorfor det er så upålideligt at kopiere en kode fra en chatbesked.

To ure skal stemme, ikke ét

Registreringsmateriale er den første fælles ting, og tid er den anden. Hvis hemmeligheden er rigtig, mens urene afviger mere end det tilladte vindue, lander hver genereret værdi i det forkerte trin og afvises. Hvis urene stemmer, mens hemmeligheden er forkert, afvises hver værdi også, og begge fejl ser identiske ud fra login-skærmen. At skelne dem betyder at kontrollere kontooplysningen og tiden uafhængigt, i den rækkefølge.

Verifikatorens ur fortjener samme granskning som enhedens. En server med en ødelagt tidskilde afviser korrekte koder fra alle brugere på én gang, og rapporterne vil beskrive et pludseligt udfald snarere end en drift. Det mønster er værd at genkende, fordi rettelsen hører på serveren og ikke på hundrede telefoner.

Hvad det koster at udvide vinduet

Implementeringer kan acceptere en kode fra et tilstødende trin for at absorbere små forskelle, og den tolerance er en designbeslutning, ikke en gratis justering. Hvert ekstra trin mangedobler antallet af værdier, der er gyldige på et givet tidspunkt, hvilket er præcis, hvad en angriber, der gætter, foretrækker. Reglen mod genafspilning er vigtig af samme grund, fordi en kode, der accepteres to gange, er en kode, der er lækket nyttigt. En administrator, der udvider vinduet for at tysse på klager, bytter en reel egenskab for en kosmetisk forbedring.

At rette uret er reparationen, mens at udvide vinduet er et beroligende middel. Det første fjerner årsagen, og det andet skjuler den.

Kontroller begge ure, før du prøver igen

Læs tiden på enheden og på serveren, og sammenlign forskellene i stedet for de viste lokale tider. Kommandoerne nedenfor viser synkroniseringstilstand og det rå UTC-tidspunkt på en Linux-vært eller -server. Kør dem i begge ender, før du ændrer nogen godkendelsesindstilling.

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

En forskel målt i sekunder er harmløs, en målt i minutter forklarer en afvisning, og et system, der ikke rapporterer nogen synkroniseringskilde, er kandidat til begge. Sammenlign de to UTC-tidsstempler direkte, da lokal tid indeholder en tidszone, som algoritmen aldrig ser. Hvis forskellene er små, og koderne stadig fejler, skal du stoppe med at justere ure og i stedet undersøge registreringsposten. Gentagne forsøg mod en låst konto gør den oprindelige fejl sværere at observere.

Notér afvisningstidspunktet, forskellen og fejlteksten, og hold den delte hemmelighed ude af det. Support kan arbejde med de første tre og bør aldrig se den fjerde.