Varför TOTP-koder misslyckas när enhetens klocka driver

Engångskoder kan vara helt korrekta på din telefon och ändå avvisas av servern i samma sekund. Båda sidor beräknar samma funktion från en delad hemlighet och det aktuella tidssteget, så oenighet om tiden ger oenighet om koden. Det gör klockdrift till ett säkerhetsrelevant fel och inte bara en irritation.

Två klockor spelar roll här, och att rätta den synliga är den del folk gör först. Den som oftast behöver uppmärksamhet är den andra.

Koden är en funktion av tid, inte ett lösenord

TOTP tar den delade hemligheten och en räknare som härleds från aktuell tid, kör båda genom en hash med nyckel och kortar resultatet till en kort decimalsträng, enligt RFC 6238. Räknaren går framåt vid varje tidssteg, vanligtvis trettio sekunder, så samma hemlighet ger ett nytt värde när steget ändras. Verifieraren räknar om det förväntade värdet för det aktuella steget och jämför, vilket kräver samma hemlighet och samma uppfattning om nuet. Ett lösenord förblir återanvändbart tills det byts, medan detta värde löper ut vid en gräns som klienten inte kan se.

Därför fungerar en kod och nästa misslyckas några ögonblick senare. Det förklarar också varför det är så opålitligt att kopiera en kod från ett chattmeddelande.

Två klockor måste stämma, inte en

Registreringsmaterialet är det första gemensamma, och tiden är det andra. Om hemligheten är rätt medan klockorna avviker mer än det tillåtna fönstret hamnar varje genererat värde i fel steg och avvisas. Om klockorna stämmer medan hemligheten är fel avvisas varje värde också, och båda felen ser identiska ut från inloggningsskärmen. Att skilja dem åt innebär att kontrollera kontoposten och tiden var för sig, i den ordningen.

Verifierarens klocka förtjänar samma granskning som enhetens. En server med trasig tidskälla avvisar korrekta koder från alla användare på en gång, och rapporterna kommer att beskriva ett plötsligt avbrott snarare än en drift. Det mönstret är värt att känna igen, eftersom rättelsen hör till servern och inte till hundra telefoner.

Vad det kostar att vidga fönstret

Implementationer kan acceptera en kod från ett närliggande steg för att absorbera små skillnader, och den toleransen är ett designbeslut, inte en gratis justering. Varje extra steg multiplicerar antalet värden som är giltiga vid varje given tidpunkt, vilket är precis vad en angripare som gissar föredrar. Regeln mot upprepning spelar roll av samma skäl, eftersom en kod som accepteras två gånger är en kod som har läckt på ett användbart sätt. En administratör som vidgar fönstret för att tysta klagomål byter en verklig egenskap mot en kosmetisk förbättring.

Att rätta klockan är reparationen, medan att vidga fönstret är ett lugnande medel. Det första tar bort orsaken och det andra döljer den.

Kontrollera båda klockorna innan du försöker igen

Läs tiden på enheten och på servern och jämför avvikelserna i stället för de visade lokala tiderna. Kommandona nedan visar synkroniseringsstatus och den råa UTC-tidpunkten på en Linux-värd eller -server. Kör dem i båda ändar innan du ändrar någon autentiseringsinställning.

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

En avvikelse mätt i sekunder är ofarlig, en mätt i minuter förklarar ett avvisande, och ett system som inte rapporterar någon synkroniseringskälla är kandidat för båda. Jämför de två UTC-tidsstämplarna direkt, eftersom lokal tid innehåller en tidszon som algoritmen aldrig ser. Om avvikelserna är små och koderna fortfarande misslyckas, sluta justera klockor och granska i stället registreringsposten. Upprepade försök mot ett låst konto gör det ursprungliga felet svårare att observera.

Anteckna avvisningstiden, avvikelsen och feltexten, och håll den delade hemligheten utanför. Support kan arbeta med de tre första och bör aldrig se den fjärde.