De ce un cod de unică folosință valid tot eșuează la autentificarea în VPN

Deschideți clientul VPN, tastați parola, iar cele șase cifre din autentificator se întorc ca nevalide — de două ori, apoi a treia oară. Nimic nu s-a schimbat în cont de ieri, așa că instinctul este să ștergeți intrarea din autentificator și să o scanați din nou — de obicei reparația greșită. Un cod de unică folosință nu este o a doua parolă: gateway-ul trebuie să îl ceară într-un anumit pas, dintr-o anumită intrare înrolată, într-o anumită fereastră, iar majoritatea respingerilor apar înainte de compararea cifrelor. Stabiliți în ce pas sunteți înainte de a atinge înrolarea.

Ordinea solicitărilor vă spune în ce flux sunteți

Trei forme acoperă aproape orice autentificare VPN care implică un cod. În forma cu două etape clientul trimite parola, serverul emite o provocare, iar clientul întreabă din nou. În forma combinată gateway-ul vrea parola și codul într-o singură trimitere — uneori concatenate, uneori după un separator pe care doar operatorul îl documentează. În forma de browser clientul nu are niciun câmp: codul merge într-o pagină web, sau o aprobare push îl înlocuiește, iar clientul desktop așteaptă rezultatul.

Forma greșită arată ca un cod prost. Lipiți un cod proaspăt într-un câmp doar pentru parolă și serverul îl va citi ca parte a parolei. Pe partea clientului, OpenVPN 2.4 și versiunile ulterioare fac diferența vizibilă: un server care răspunde cu AUTH_FAILED,CRV1: așteaptă un răspuns la provocare, așa că profilul are nevoie de static-challenge sau de un fișier de parole în forma SCRV1:. Un profil mai vechi care are doar auth-user-pass validează parola și apoi se blochează, ceea ce în jurnal arată ca o eroare OTP deși nu a fost trimis niciun cod.

WireGuard merită menționat ca excepția: autentifică perechi de chei, nu oameni, așa că nu există niciun câmp pentru un cod. Dacă un furnizor anunță unul, ceva din afara tunelului îl acceptă.

Ce face serverul cu cele șase cifre

Codurile bazate pe timp urmează RFC 6238, care împachetează construcția mai veche bazată pe contor din RFC 4226: un HMAC peste un factor mobil, trunchiat la șase cifre în mod implicit. La TOTP factorul mobil este timpul Unix curent împărțit la un pas, 30 de secunde dacă operatorul nu l-a schimbat. Verificatorul nu compară niciodată cifrele dumneavoastră cu o valoare stocată; recalculează codul așteptat din sămânța comună și de obicei acceptă și pașii vecini, așa că un drum dus-întors lent nu face autentificarea să eșueze.

Două consecințe trec neobservate. Fusul orar al telefonului este irelevant, pentru că sămânța nu vede niciodată un ceas local — contează doar abaterea față de UTC real, iar un aparat care merge cu două minute înainte eșuează la fiecare cod afișând o numărătoare inversă curată. Și un cod este de unică folosință prin proiectare: verificatorul reține ultima valoare de contor pe care a acceptat-o pentru acea sămânță, așa că aceleași cifre trimise din nou sunt respinse chiar și în aceeași fereastră. Un client care reîncearcă după un timeout poate arde codul pe care tocmai l-a trimis.

Tokenurile bazate pe contor își deplasează contorul la fiecare apăsare, așa că ies din sincronizare după ce s-au generat coduri care nu au fost niciodată trimise; reparația obișnuită este o fereastră de resincronizare care acceptă câteva valori înainte. Dacă operatorul a înrolat HOTP, iar aplicația dumneavoastră afișează TOTP, fiecare valoare este greșită într-un mod care arată ca o problemă de ceas. URI-ul de aprovizionare din spatele codului QR numește tipul, cifrele, perioada și hash-ul.

Eșecuri care arată ca un cod greșit

Intrarea înrolată este vinovatul cel mai frecvent. Aplicațiile de autentificare etichetează intrările după emitent și cont, așa că cine are două identități pe același VPN poate ajunge cu două intrări ale căror etichete diferă printr-un caracter. Un cod este valid pentru sămânța care l-a generat și pentru nimic altceva. Comparați eticheta de pe telefon cu numele de utilizator pe care serverul îl înregistrează, nu cu ceea ce vă amintiți că ați tastat.

Al doilea este un set de parametri care nu se potrivește. O sămânță înrolată cu opt cifre, o perioadă de 60 de secunde sau SHA-256 produce coduri pe care un verificator care așteaptă șase cifre, 30 de secunde și SHA-1 le respinge, iar la client acest lucru este de nedistins de un cod greșit. Apare după migrări în care intrarea a fost adăugată din nou dintr-o fotografie a codului QR sau în care înregistrarea tokenului a fost reconstruită cu valori implicite.

Al treilea nu este despre cod. Gateway-urile returnează de obicei o singură eroare generică de autentificare pentru parolă greșită, cod expirat și cont dezactivat, în mod deliberat, ca nimeni să nu poată investiga care factor a eșuat. Citiți jurnalul gateway-ului sau al RADIUS în locul bannerului clientului: o provocare niciodată emisă, un refuz de acces fără atribut OTP și o respingere de politică arată la fel pe ecran și duc la pași următori diferiți.

O secvență scurtă care îl restrânge

Începeți cu verificarea cea mai ieftină și opriți-vă la primul pas care nu se susține.

1. Așteptați un cod proaspăt, trimiteți-l o dată și notați dacă provocarea apare înainte sau după acceptarea parolei.
2. Potriviți eticheta din autentificator cu numele de utilizator pe care serverul îl stochează.
3. Confirmați că profilul poate răspunde la o provocare, ca în cazul CRV1 de mai sus.
4. Comparați ceasul dispozitivului cu o sursă de timp cunoscută; o abatere de peste câteva zeci de secunde strică TOTP de la sine.
5. Întrebați operatorul dacă tokenul este TOTP sau HOTP și ce cifre, perioadă și hash au fost înrolate.

Două reguli împiedică înrăutățirea situației. Nu reîncercați de multe ori: multe gateway-uri numără eșecurile pe cont și fie îl blochează, fie încep să întârzie răspunsurile, așa că o rafală transformă o mică eroare de configurare într-un tichet de asistență. Și nu reînrolați tokenul ca diagnostic, pentru că asta invalidează sămânța veche; dacă defecțiunea reală a fost o provocare pe care clientul nu a trimis-o niciodată, acum aveți două modificări de explicat în loc de una.

Țineți sămânța și codurile de recuperare în afara circuitului

Cele șase cifre și secretul din spatele lor nu sunt interschimbabile. Un cod QR de aprovizionare sau o sămânță Base32 generează fiecare cod viitor al contului, așa că aparține aceleiași categorii ca parola: nu într-o captură de ecran, nu într-un comentariu la un tichet, nu într-o conversație cu cineva care v-a contactat primul. Codurile de recuperare sunt un mecanism separat — de unică folosință, adesea sar complet peste solicitarea codului, iar consumarea unuia pentru a testa contul elimină o cale de rezervă de care ați putea avea nevoie mai târziu.

Un cod nu face nici o pagină de autentificare demnă de încredere: o solicitare OTP pe un domeniu similar colectează un cod valid și îl redă din nou în fereastră, iar certificatul este în continuare ceea ce vă spune unde tastați.

Dacă secvența se termină pe un profil care nu poate răspunde la o provocare, reparați profilul și retestați cu un cod proaspăt. Dacă se termină pe parametri de înrolare care nu se potrivesc, rugați operatorul să citească înregistrarea tokenului înainte ca cineva să scaneze ceva. Dacă se termină pe o blocare, așteptați să treacă în loc să schimbați clientul — starea contului este obstacolul, nu aplicația.