Unde ajunge codul provocării statice într-o autentificare OpenVPN

Clientul afișează o a doua casetă după câmpul parolei, tastați codul de pe tokenul hardware, iar autentificarea eșuează în continuare cu o eroare de autentificare. Acea casetă există, deci profilul a cerut-o. Dacă serverul a primit vreodată valoarea într-o formă pe care o înțelege este altă întrebare, și este cea care merită lămurită prima.

Începeți cu mesajul pe care clientul îl afișează cu adevărat

Un profil poate purta o directivă de provocare statică cu un șir de mesaj și un indicator care controlează dacă răspunsul este afișat în timp ce tastați. Mesajul este ceea ce vedeți în dialog; indicatorul este o preferință de afișare pentru aceeași intrare. Niciunul nu îi spune serverului cum să verifice ceva.

Numărați câmpurile care v-au fost date cu adevărat. Un câmp pentru numele de utilizator plus un câmp mascat este o autentificare obișnuită cu parolă, fără nicio provocare. Un al doilea câmp care apare după parolă, cu propria etichetă, este clientul care implementează interacțiunea provocării.

Dacă a doua casetă nu apare niciodată în clientul pe care îl folosiți, acel client poate să nu implementeze interacțiunea, sau să o implementeze doar printr-o altă interfață, cum ar fi o interfață de administrare. Verificarea clientului costă mai puțin decât rescrierea profilului, și de obicei acolo se află de fapt nepotrivirea.

Ce trebuie serverul să accepte deja

Profilul descrie ce trebuie să colecteze clientul. Nu activează verificarea pe server, iar un server fără integrarea de autentificare corespunzătoare va primi pur și simplu o parolă pe care nu o recunoaște. De aceea unele instalări afișează mesajul și resping fiecare cod, și de aceea răspunsul operatorului despre ce mecanism face verificarea este cel care contează.

Întrebați operatorul ce mecanism face verificarea. Poate fi un modul care vorbește cu PAM, un cârlig de script care validează răspunsul față de un serviciu de tokenuri, sau o integrare bazată pe administrare care analizează ea însăși valoarea împachetată. Fiecare dintre ele așteaptă o intrare ușor diferită.

Aici trebuie calibrate și așteptările. Un al doilea mesaj este un mecanism de intrare, nu dovada că se aplică un al doilea factor, pentru că aplicarea are loc pe partea serverului și se vede doar când testați un cod greșit.

Câmpul codificat pe care îl trimite interfața de administrare

Când o interfață conduce conexiunea prin interfața de administrare, parola și răspunsul la provocare sunt împachetate într-o singură valoare înainte de trimitere. Referința interfeței de administrare documentează formatul: un prefix, apoi parola și răspunsul ca componente Base64 separate.

Base64 este o codificare, nu o protecție. Nu ascunde nimic de cine poate citi câmpul și nu transformă un cod de unică folosință în ceva reutilizabil. Valoarea împachetată merită același tratament ca o parolă: în afara profilurilor partajate, în afara liniilor de comandă și în afara jurnalelor de diagnosticare.

Această codificare este și cea mai frecventă sursă de confuzie, pentru că acum există trei forme care arată asemănător și nu sunt interschimbabile. Un fișier simplu de acreditări conține o parolă. O concatenare literală a parolei și a codului conține un alt șir. Răspunsul împachetat al unui client de administrare conține o a treia. Confirmați pe care o așteaptă calea dumneavoastră de verificare înainte de a schimba un câmp doar pentru că a dispărut o eroare.

Static versus dinamic: moment diferit

O provocare statică este cunoscută înainte de trimiterea primei acreditări, așa că clientul o poate cere dinainte. O provocare dinamică sosește mai târziu, trimisă de fluxul de autentificare după ce un schimb a început deja, și are nevoie de un client care poate trata o cerere în mijlocul conversației.

Suportul pentru una nu o oferă pe cealaltă. O directivă de profil care configurează un mesaj static nu implementează o provocare inițiată de server, iar o interfață care tratează cereri dinamice poate tot nu afișa una statică. Citirea părții care a inițiat cererea este cea mai rapidă cale de a le distinge.

Funcționarea nesupravegheată este locul unde aceasta devine o chestiune de proiectare, nu de interfață. Un cod salvat nu este o acreditare durabilă la pornire, iar o reconectare ore mai târziu va avea nevoie de o intrare nouă, dacă implementarea nu acceptă o aranjare de tokenuri pe care operatorul a activat-o în mod deliberat.

Testați atât succesul, cât și eșecul, nu doar dialogul

Rulați ambele jumătăți ale testului. Acreditările corecte cu un răspuns valid ar trebui să reușească; acreditările corecte cu un răspuns greșit în mod deliberat ar trebui respinse. Dacă ambele reușesc, clientul colectează o intrare pe care nimic nu o verifică, iar dialogul a fost confundat cu un control. Acel singur test prinde mai multe instalări decât orice revizuire de profil.

Apoi repetați conexiunea după o reconectare, cu un cont care nu este înregistrat, și prin clientul pe care utilizatorii dumneavoastră îl rulează cu adevărat. Apariția mesajului este un comportament al clientului; respingerea unui cod greșit este serverul care impune ceva.