Hvorfor TOTP-koder feiler når enhetens klokke driver

Engangskoder kan være helt korrekte på telefonen din og likevel avvises av serveren i samme sekund. Begge sider regner ut den samme funksjonen fra en delt hemmelighet og det gjeldende tidstrinnet, så uenighet om tiden gir uenighet om koden. Det gjør klokkedrift til en sikkerhetsrelevant feil og ikke bare en irritasjon.

To klokker betyr noe her, og å rette den synlige er den delen folk gjør først. Den som vanligvis trenger oppmerksomhet, er den andre.

Koden er en funksjon av tid, ikke et passord

TOTP tar den delte hemmeligheten og en teller utledet fra gjeldende tid, kjører begge gjennom en hash med nøkkel og avkorter resultatet til en kort desimalstreng, som angitt i RFC 6238. Telleren går fremover ved hvert tidstrinn, vanligvis tretti sekunder, så den samme hemmeligheten gir en ny verdi når trinnet endres. Verifisereren regner ut den forventede verdien for gjeldende trinn på nytt og sammenligner, noe som krever den samme hemmeligheten og den samme oppfatningen av nå. Et passord forblir gjenbrukbart til det endres, mens denne verdien utløper på en grense klienten ikke kan se.

Derfor virker én kode og den neste feiler noen øyeblikk senere. Det forklarer også hvorfor det er så upålitelig å kopiere en kode fra en chatmelding.

To klokker må stemme, ikke én

Registreringsmaterialet er det første felles, og tiden er det andre. Hvis hemmeligheten er riktig mens klokkene avviker mer enn det tillatte vinduet, havner hver generert verdi i feil trinn og avvises. Hvis klokkene stemmer mens hemmeligheten er feil, avvises hver verdi også, og begge feilene ser identiske ut fra påloggingsskjermen. Å skille dem betyr å kontrollere kontoinnføringen og tiden uavhengig, i den rekkefølgen.

Verifisererens klokke fortjener samme gransking som enhetens. En server med ødelagt tidskilde avviser riktige koder fra alle brukere samtidig, og rapportene vil beskrive et plutselig utfall snarere enn en drift. Det mønsteret er verdt å kjenne igjen, fordi rettelsen hører på serveren og ikke på hundre telefoner.

Hva det koster å utvide vinduet

Implementasjoner kan godta en kode fra et tilstøtende trinn for å absorbere små forskjeller, og den toleransen er en designbeslutning, ikke en gratis justering. Hvert ekstra trinn multipliserer antallet verdier som er gyldige til enhver tid, og det er nettopp det en angriper som gjetter foretrekker. Regelen mot gjenbruk betyr noe av samme grunn, siden en kode som godtas to ganger er en kode som har lekket nyttig. En administrator som utvider vinduet for å tysse på klager, bytter en reell egenskap mot en kosmetisk forbedring.

Å rette klokken er reparasjonen, mens å utvide vinduet er et beroligende middel. Det første fjerner årsaken, og det andre skjuler den.

Kontroller begge klokkene før du prøver igjen

Les tiden på enheten og på serveren, og sammenlign avvikene i stedet for de viste lokale tidene. Kommandoene nedenfor viser synkroniseringstilstand og det rå UTC-tidspunktet på en Linux-vert eller -server. Kjør dem i begge ender før du endrer noen autentiseringsinnstilling.

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

Et avvik målt i sekunder er ufarlig, et målt i minutter forklarer en avvisning, og et system som ikke rapporterer noen synkroniseringskilde, er kandidat for begge. Sammenlign de to UTC-tidsstempelene direkte, siden lokal tid inneholder en tidssone algoritmen aldri ser. Hvis avvikene er små og kodene fortsatt feiler, slutt å justere klokker og undersøk registreringsoppføringen i stedet. Gjentatte forsøk mot en låst konto gjør den opprinnelige feilen vanskeligere å observere.

Noter avvisningstiden, avviket og feilteksten, og hold den delte hemmeligheten utenfor. Støtte kan jobbe med de tre første og bør aldri se den fjerde.