Kam patří kód statické výzvy při přihlášení OpenVPN

Klient zobrazí druhé pole za polem hesla, zadáte kód z hardwarového tokenu a přihlášení přesto selže s chybou ověřování. To pole existuje, takže si ho profil vyžádal. Zda server někdy dostal hodnotu ve formě, které rozumí, je jiná otázka a právě na tu je třeba odpovědět nejprve.

Začněte výzvou, kterou váš klient skutečně zobrazuje

Profil může nést direktivu statické výzvy s textem výzvy a příznakem, který řídí, zda se odpověď zobrazuje při psaní. Výzva je to, co vidíte v dialogu; příznak je preference zobrazení pro stejný vstup. Ani jedno neříká serveru, jak něco ověřovat.

Spočítejte pole, která jste skutečně dostali. Jedno pole pro uživatelské jméno plus jedno maskované pole je běžné přihlášení heslem zcela bez výzvy. Druhé pole, které se objeví po heslu a má vlastní popisek, je klient, který implementuje interakci výzvy.

Pokud se druhé pole v klientovi, kterého používáte, nikdy neobjeví, tento klient interakci možná neimplementuje, nebo ji implementuje jen přes jiné rozhraní, například rozhraní pro správu. Zkontrolovat klienta je levnější než přepisovat profil a obvykle právě tam nesoulad skutečně sídlí.

Co musí server už podporovat

Profil popisuje, co má klient shromáždit. Nezapíná ověřování na serveru a server bez odpovídající integrace ověřování prostě dostane heslo, které nezná. Proto některá nasazení zobrazují výzvu a odmítají každý kód a proto je odpověď operátora o tom, který mechanismus kontrolu provádí, tou, na které záleží.

Zeptejte se operátora, který mechanismus kontrolu provádí. Může to být plugin, který mluví s PAM, skriptový hook, který ověřuje odpověď proti službě tokenů, nebo integrace založená na správě, která zabalenou hodnotu analyzuje sama. Každý z nich očekává trochu jiný vstup.

Zde je také třeba kalibrovat očekávání. Druhá výzva je vstupní mechanismus, ne důkaz, že se uplatňuje druhý faktor, protože uplatnění probíhá na straně serveru a projeví se jen při testu špatného kódu.

Kódované pole, které posílá rozhraní pro správu

Když front end řídí připojení přes rozhraní pro správu, heslo a odpověď na výzvu se před odesláním zabalí do jedné hodnoty. Reference rozhraní pro správu popisuje formát: prefix a poté heslo a odpověď jako samostatné komponenty Base64.

Base64 je kódování, ne ochrana. Před nikým, kdo pole umí přečíst, nic neskryje a jednorázový kód nepřemění na něco znovu použitelného. Zabalená hodnota si zaslouží stejné zacházení jako heslo: pryč ze sdílených profilů, z příkazových řádků a z diagnostických protokolů.

Toto kódování je také nejčastějším zdrojem zmatení, protože nyní existují tři tvary, které vypadají podobně a nejsou zaměnitelné. Prostý soubor přihlašovacích údajů obsahuje heslo. Doslovné spojení hesla a kódu obsahuje jiný řetězec. Zabalená odpověď klienta správy obsahuje třetí. Než změníte pole jen proto, že chyba zmizela, potvrďte, který z nich vaše cesta ověřování očekává.

Statická versus dynamická: jiné načasování

Statická výzva je známa před odesláním prvních přihlašovacích údajů, takže o ni klient může požádat předem. Dynamická výzva přichází později, posílá ji pracovní postup ověřování poté, co výměna už začala, a potřebuje klienta, který zvládne požadavek uprostřed konverzace.

Podpora jednoho vám nedá druhé. Direktiva profilu, která nastavuje statickou výzvu, neimplementuje výzvu iniciovanou serverem a front end, který zvládá dynamické požadavky, stále nemusí zobrazit statickou. Čtení toho, která strana požadavek zahájila, je nejrychlejší způsob, jak je rozlišit.

Bezobslužný provoz je místo, kde se to stává otázkou návrhu, nikoli rozhraní. Uložený kód není trvalý přihlašovací údaj pro start a opětovné připojení po hodinách bude potřebovat nový vstup, pokud nasazení nepodporuje uspořádání tokenů, které operátor záměrně povolil.

Testujte úspěch i selhání, ne jen dialog

Proveďte obě poloviny testu. Správné přihlašovací údaje s platnou odpovědí by měly projít; správné přihlašovací údaje se záměrně špatnou odpovědí by měly být odmítnuty. Pokud projdou obě, klient shromažďuje vstup, který nic neověřuje, a dialog byl zaměněn za kontrolu. Ten jediný test odhalí více nasazení než jakákoli revize profilu.

Poté zopakujte připojení po opětovném připojení, s účtem, který není zapsán, a přes klienta, který vaši uživatelé skutečně používají. Zobrazení výzvy je chování klienta; odmítnutí špatného kódu je server, který něco vynucuje.