OpenVPN închide mai târziu o sesiune OTP: ce presupune reautentificarea
O sesiune care moare după o oră este de obicei o renegociere de chei care cere un cod deja folosit. Alege între un token emis de server și o nouă provocare interactivă.
Din partea clientului arată ca o deconectare aleatorie la o oră după începerea unei sesiuni de lucru. Pictograma din tavă dispare, tunelul este reconstruit, iar jurnalul arată o eroare de autentificare în loc de o eroare de rețea. Ce s-a întâmplat de fapt este că sesiunea a renegociat și al doilea handshake a avut nevoie de acreditări pentru care clientul nu mai avea o copie validă. Un cod de unică folosință care a funcționat la autentificare nu poate funcționa din nou, așa că renegocierea cheii eșuează exact cum a fost proiectată.
Soluția este o decizie despre ce trebuie să prezinte al doilea handshake, nu un temporizator de reîncercare mai lung.
Parcurge schimbul din perspectiva clientului
La autentificare clientul trimite numele de utilizator, parola și un cod de la dispozitivul token, iar serverul acceptă combinația. Apoi sesiunea rulează până când se declanșează un trigger de renegociere, care pornește un handshake TLS nou în tunelul existent. Acel handshake cere din nou autentificare. Dacă calea de autentificare a serverului așteaptă o parolă plus un cod de unică folosință curent, clientul nu are un cod nou de oferit decât dacă utilizatorul este prezent să-l tasteze.
Majoritatea clienților nu deschid o solicitare la mijlocul sesiunii, așa că handshake-ul expiră și tunelul cade. Utilizatorul vede o reconectare, nu o solicitare de autentificare, motiv pentru care primul raport dă de obicei vina pe rețea.
auth-gen-token schimbă cine răspunde la a doua întrebare
Opțiunea auth-gen-token permite serverului să emită un token după o autentificare reușită, iar renegocierile ulterioare prezintă acel token în loc să repete parola și codul. Manualul documentează durata de viață și comportamentul de reînnoire, iar tokenul trebuie tratat ca o acreditare cu propria expirare. Pe calea implicită serverul validează singur tokenul în loc să apeleze din nou autentificatorul extern de parole.
Cu o integrare de autentificare externă, acea împărțire se schimbă. Pluginul trebuie să înțeleagă starea tokenului și să aplice propriile verificări, pentru că serverul nu mai este singura componentă care decide dacă sesiunea continuă. Tratarea tokenului ca încă un cod de unică folosință numeric nu este o implementare a funcției.
Decide ce se întâmplă cu starea contului
Un token care supraviețuiește accesului unui cont este o gaură în politică. Decide cum un cont dezactivat, o apartenență la grup eliminată sau un dispozitiv revocat își fac efectul cât timp tokenul este încă valid. Durate scurte de viață reduc fereastra; o cale explicită de revocare o face intenționată. Scrie răspunsul înainte de a activa opțiunea, pentru că calea implicită nu consultă autentificatorul extern la fiecare renegociere.
Într-o implementare cu mai multe servere, secretul de semnare a tokenului trebuie partajat, altfel clientul poate fi trimis la un nod care nu îi poate valida tokenul.
Testează expirarea și reconectarea, nu doar autentificarea
Reduce intervalul de renegociere într-un profil de test ca al doilea handshake să aibă loc sub ochii tăi, apoi urmărește ambele jurnale. Confirmă că tokenul este emis la autentificare, prezentat la renegocierea cheii și reînnoit sau reemis conform duratei configurate. Apoi forțează expirarea tokenului și o reconectare completă, pentru că un client care se reconectează curat poate eșua totuși pe calea renegocierii cheii.
Testează eliminarea contului la final. Acel caz îți spune dacă politica scrisă este aplicată sau doar documentată.
Nu repara prin dezactivarea reînnoirii
Setarea intervalului de renegociere la zero pe ambii parteneri elimină simptomul și, odată cu el, rotația cheilor. Asta ascunde o problemă de reluare a acreditărilor în spatele unei schimbări de politică pe care nimeni nu a revizuit-o. Păstrează reînnoirea și alege între un token emis de server și o nouă provocare interactivă în funcție de prezența unui utilizator.
Un temporizator de reîncercare mai lung nu face un cod consumat din nou valid. Doar întârzie deconectarea și face jurnalul mai greu de citit.