De ce codurile TOTP eșuează când ceasul dispozitivului derivează

Codurile de unică folosință pot fi perfect corecte pe telefonul dumneavoastră și totuși respinse de server în aceeași secundă. Ambele părți calculează aceeași funcție dintr-un secret comun și din pasul de timp curent, așa că o neînțelegere privind timpul produce o neînțelegere privind codul. Asta face derivarea ceasului o defecțiune relevantă pentru securitate, nu doar o neplăcere.

Aici contează două ceasuri, iar corectarea celui vizibil este partea pe care oamenii o fac prima. Cel care de obicei are nevoie de atenție este celălalt.

Codul este o funcție a timpului, nu o parolă

TOTP ia secretul comun și un contor derivat din timpul curent, trece ambele printr-un hash cu cheie și trunchiază rezultatul la un șir zecimal scurt, conform RFC 6238. Contorul avansează la fiecare pas de timp, de obicei treizeci de secunde, așa că același secret produce o valoare nouă când pasul se schimbă. Verificatorul recalculează valoarea așteptată pentru pasul curent și compară, ceea ce cere același secret și aceeași idee despre prezent. O parolă rămâne reutilizabilă până când este schimbată, în timp ce această valoare expiră la o limită pe care clientul nu o vede.

De aceea un cod funcționează, iar următorul eșuează câteva clipe mai târziu. Asta explică și de ce copierea unui cod dintr-un mesaj de chat este un obicei atât de nesigur.

Două ceasuri trebuie să fie de acord, nu unul

Materialul de înregistrare este primul lucru comun, iar timpul este al doilea. Dacă secretul este corect în timp ce ceasurile diferă mai mult decât fereastra tolerată, fiecare valoare generată ajunge în pasul greșit și este respinsă. Dacă ceasurile sunt de acord în timp ce secretul este greșit, fiecare valoare este și ea respinsă, și ambele eșecuri arată identic pe ecranul de autentificare. Separarea lor înseamnă verificarea înregistrării contului și a timpului separat, în această ordine.

Ceasul verificatorului merită aceeași examinare ca cel al dispozitivului. Un server cu sursa de timp defectă respinge coduri corecte de la toți utilizatorii deodată, iar rapoartele vor descrie o întrerupere bruscă, nu o derivare. Merită recunoscut acest tipar, pentru că remedierea lui aparține serverului, nu unei sute de telefoane.

Cât costă lărgirea ferestrei

Implementările pot accepta un cod dintr-un pas adiacent pentru a absorbi diferențe mici, iar această toleranță este o decizie de proiectare, nu o ajustare gratuită. Fiecare pas suplimentar înmulțește numărul de valori valabile în orice moment, exact ceea ce preferă un atacator care ghicește. Regula anti-repetare contează din același motiv, fiindcă un cod acceptat de două ori este un cod care a scăpat în mod util. Un administrator care lărgește fereastra pentru a înăbuși reclamațiile schimbă o proprietate reală pe o îmbunătățire cosmetică.

Corectarea ceasului este reparația, în timp ce lărgirea ferestrei este un sedativ. Prima elimină cauza, iar a doua o ascunde.

Verificați ambele ceasuri înainte de a reîncerca

Citiți timpul pe dispozitiv și pe server și comparați decalajele, nu orele locale afișate. Comenzile de mai jos arată starea de sincronizare și momentul UTC brut pe un host sau server Linux. Rulați-le la ambele capete înainte de a schimba orice setare de autentificare.

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

Un decalaj măsurat în secunde este inofensiv, unul măsurat în minute explică o respingere, iar un sistem care nu raportează nicio sursă de sincronizare este candidat pentru ambele. Comparați direct cele două momente UTC, fiindcă ora locală include un fus orar pe care algoritmul nu îl vede niciodată. Dacă decalajele sunt mici și codurile încă eșuează, opriți ajustarea ceasurilor și inspectați în schimb înregistrarea. Încercările repetate împotriva unui cont blocat fac defectul inițial mai greu de observat.

Notați momentul respingerii, decalajul și textul erorii, și lăsați secretul comun în afara acestora. Suportul poate lucra cu primele trei și nu ar trebui să vadă niciodată al patrulea.