Kam patrí kód statickej výzvy pri prihlásení do OpenVPN

Klient zobrazí druhé pole za poľom hesla, zadáte kód z hardvérového tokenu a prihlásenie napriek tomu zlyhá s chybou overenia. To pole existuje, takže si ho profil vyžiadal. Či server niekedy dostal hodnotu vo forme, ktorej rozumie, je iná otázka a práve na tú treba odpovedať najprv.

Začnite výzvou, ktorú váš klient skutočne zobrazuje

Profil môže niesť direktívu statickej výzvy s textom výzvy a príznakom, ktorý riadi, či sa odpoveď zobrazuje počas písania. Výzva je to, čo vidíte v dialógu; príznak je preferencia zobrazenia pre ten istý vstup. Ani jedno nehovorí serveru, ako niečo overovať.

Spočítajte polia, ktoré ste skutočne dostali. Jedno pole pre používateľské meno plus jedno maskované pole je bežné prihlásenie heslom celkom bez výzvy. Druhé pole, ktoré sa objaví po hesle a má vlastný popisok, je klient, ktorý implementuje interakciu výzvy.

Ak sa druhé pole v klientovi, ktorého používate, nikdy neobjaví, tento klient interakciu možno neimplementuje, alebo ju implementuje len cez iné rozhranie, napríklad rozhranie na správu. Skontrolovať klienta je lacnejšie ako prepisovať profil a nezrovnalosť zvyčajne skutočne sídli práve tam.

Čo musí server už podporovať

Profil opisuje, čo má klient zhromaždiť. Nezapína overovanie na serveri a server bez zodpovedajúcej integrácie overovania jednoducho dostane heslo, ktoré nepozná. Preto niektoré nasadenia zobrazujú výzvu a odmietajú každý kód a preto je odpoveď operátora o tom, ktorý mechanizmus kontrolu vykonáva, tou, na ktorej záleží.

Opýtajte sa operátora, ktorý mechanizmus kontrolu vykonáva. Môže to byť plugin, ktorý hovorí s PAM, skriptový hák, ktorý overuje odpoveď voči službe tokenov, alebo integrácia založená na správe, ktorá zabalenú hodnotu analyzuje sama. Každý z nich očakáva trochu iný vstup.

Tu treba tiež kalibrovať očakávania. Druhá výzva je vstupný mechanizmus, nie dôkaz, že sa uplatňuje druhý faktor, pretože uplatnenie prebieha na strane servera a prejaví sa až pri teste nesprávneho kódu.

Kódované pole, ktoré posiela rozhranie na správu

Keď front end riadi pripojenie cez rozhranie na správu, heslo a odpoveď na výzvu sa pred odoslaním zabalia do jednej hodnoty. Referencia rozhrania na správu opisuje formát: prefix a potom heslo a odpoveď ako samostatné komponenty Base64.

Base64 je kódovanie, nie ochrana. Pred nikým, kto pole vie prečítať, nič neskryje a jednorazový kód nepremení na niečo znovu použiteľné. Zabalená hodnota si zaslúži rovnaké zaobchádzanie ako heslo: preč zo zdieľaných profilov, z príkazových riadkov a z diagnostických protokolov.

Toto kódovanie je aj najčastejším zdrojom zmätku, pretože teraz existujú tri tvary, ktoré vyzerajú podobne a nie sú zameniteľné. Obyčajný súbor prihlasovacích údajov obsahuje heslo. Doslovné spojenie hesla a kódu obsahuje iný reťazec. Zabalená odpoveď klienta správy obsahuje tretí. Pred zmenou poľa len preto, že chyba zmizla, potvrďte, ktorý z nich vaša cesta overovania očakáva.

Statická verzus dynamická: iné načasovanie

Statická výzva je známa pred odoslaním prvých prihlasovacích údajov, takže o ňu klient môže požiadať vopred. Dynamická výzva prichádza neskôr, posiela ju postup overovania po tom, ako výmena už začala, a potrebuje klienta, ktorý zvládne požiadavku uprostred konverzácie.

Podpora jedného vám nedá druhé. Direktíva profilu, ktorá nastavuje statickú výzvu, neimplementuje výzvu iniciovanú serverom a front end, ktorý zvláda dynamické požiadavky, stále nemusí zobrazovať statickú. Čítanie toho, ktorá strana požiadavku začala, je najrýchlejší spôsob, ako ich rozlíšiť.

Bezobslužná prevádzka je miesto, kde sa to stáva otázkou návrhu, nie rozhrania. Uložený kód nie je trvalý prihlasovací údaj pri štarte a opätovné pripojenie po hodinách bude potrebovať čerstvý vstup, ak nasadenie nepodporuje usporiadanie tokenov, ktoré operátor zámerne povolil.

Testujte úspech aj zlyhanie, nielen dialóg

Vykonajte obe polovice testu. Správne prihlasovacie údaje s platnou odpoveďou by mali prejsť; správne prihlasovacie údaje so zámerne nesprávnou odpoveďou by mali byť odmietnuté. Ak prejdú obe, klient zhromažďuje vstup, ktorý nič neoveruje, a dialóg bol zamenený za kontrolu. Ten jediný test odhalí viac nasadení než akákoľvek revízia profilu.

Potom zopakujte pripojenie po opätovnom pripojení, s účtom, ktorý nie je zaregistrovaný, a cez klienta, ktorého vaši používatelia skutočne používajú. Zobrazenie výzvy je správanie klienta; odmietnutie nesprávneho kódu je server, ktorý niečo vynucuje.