Hová kerül a statikus kihívás kódja egy OpenVPN-bejelentkezésnél

A kliens második mezőt mutat a jelszó mező után, beírja a kódot a hardvertokenről, és a bejelentkezés továbbra is hitelesítési hibával hiúsul meg. Az a mező létezik, tehát a profil kérte. Hogy a kiszolgáló valaha megkapta-e az értéket olyan formában, amelyet megért, más kérdés, és ezt érdemes először megválaszolni.

Kezdje azzal a felszólítással, amelyet a kliense valóban mutat

Egy profil hordozhat statikus kihívás direktívát egy felszólítás-szöveggel és egy jelzővel, amely szabályozza, hogy a válasz látható-e gépelés közben. A felszólítás az, amit a párbeszédablakban lát; a jelző ugyanannak a bevitelnek a megjelenítési beállítása. Egyik sem mondja meg a kiszolgálónak, hogyan ellenőrizzen bármit.

Számolja meg a ténylegesen kapott mezőket. Egy mező a felhasználónévhez plusz egy maszkolt mező szokásos jelszavas bejelentkezés, mindenféle kihívás nélkül. A jelszó után saját címkével megjelenő második mező a kliens, amely megvalósítja a kihívás interakciót.

Ha a második mező soha nem jelenik meg a használt kliensben, az a kliens talán nem valósítja meg az interakciót, vagy csak egy másik felületen, például egy felügyeleti interfészen keresztül teszi. A kliens ellenőrzése olcsóbb, mint a profil újraírása, és általában valóban ott van az eltérés.

Mit kell a kiszolgálónak már támogatnia

A profil leírja, mit gyűjtsön a kliens. Nem kapcsolja be az ellenőrzést a kiszolgálón, és a megfelelő hitelesítési integráció nélküli kiszolgáló egyszerűen kap egy jelszót, amelyet nem ismer fel. Ezért mutatnak egyes telepítések felszólítást és utasítanak el minden kódot, és ezért számít az üzemeltető válasza arról, melyik mechanizmus végzi az ellenőrzést.

Kérdezze meg az üzemeltetőt, melyik mechanizmus végzi az ellenőrzést. Lehet egy PAM-mal beszélő bővítmény, egy szkriptkampó, amely a választ egy token-szolgáltatással szemben ellenőrzi, vagy egy felügyeleti alapú integráció, amely maga elemzi a becsomagolt értéket. Mindegyikük kissé más bevitelt vár.

Itt kell az elvárásokat is kalibrálni. A második felszólítás beviteli mechanizmus, nem bizonyíték arra, hogy második tényezőt kényszerítenek ki, mert a kikényszerítés a kiszolgáló oldalán történik, és csak akkor látszik, amikor rossz kódot tesztel.

A kódolt mező, amelyet a felügyeleti interfész küld

Amikor egy felület a felügyeleti interfészen keresztül vezérli a kapcsolatot, a jelszó és a kihívásválasz beküldés előtt egyetlen értékbe csomagolódik. A felügyeleti interfész referenciája dokumentálja a formátumot: egy előtag, majd a jelszó és a válasz külön Base64 komponensként.

A Base64 kódolás, nem védelem. Semmit nem rejt el az elől, aki olvasni tudja a mezőt, és nem tesz egy egyszeri kódot újrahasználhatóvá. A becsomagolt érték ugyanazt a bánásmódot érdemli, mint a jelszó: ki a megosztott profilokból, ki a parancssorokból és ki a diagnosztikai naplókból.

Ez a kódolás a leggyakoribb zavarforrás is, mert most három forma van, amelyek hasonlónak látszanak, és nem cserélhetők fel. Egy egyszerű hitelesítőadat-fájl jelszót tartalmaz. A jelszó és a kód szó szerinti összefűzése másik karakterláncot tartalmaz. Egy felügyeleti kliens becsomagolt válasza egy harmadikat tartalmaz. Erősítse meg, melyiket várja az ellenőrzési útvonala, mielőtt megváltoztat egy mezőt csak azért, mert eltűnt egy hiba.

Statikus kontra dinamikus: eltérő időzítés

A statikus kihívás az első hitelesítő adat beküldése előtt ismert, így a kliens előre kérheti. A dinamikus kihívás később érkezik, a hitelesítési folyamat küldi, miután már elkezdődött egy csere, és olyan kliens kell hozzá, amely képes kezelni egy kérést a beszélgetés közepén.

Az egyik támogatása nem adja a másikat. Egy statikus felszólítást beállító profil-direktíva nem valósít meg kiszolgáló által kezdeményezett kihívást, és egy dinamikus kéréseket kezelő felület továbbra sem feltétlenül mutat statikusat. Annak olvasása, melyik fél kezdeményezte a kérést, a leggyorsabb módja az elkülönítésüknek.

A felügyelet nélküli üzemeltetés az a pont, ahol ez tervezési kérdéssé válik, nem felületi kérdéssé. Egy elmentett kód nem tartós indítási hitelesítő adat, és egy órákkal későbbi újracsatlakozás friss bevitelt igényel, hacsak a telepítés nem támogat olyan token-elrendezést, amelyet az üzemeltető szándékosan engedélyezett.

Tesztelje a sikert és a kudarcot, ne csak a párbeszédablakot

Futtassa le a teszt mindkét felét. A helyes hitelesítő adatok érvényes válasszal sikeresek legyenek; a helyes hitelesítő adatok szándékosan rossz válasszal legyenek elutasítva. Ha mindkettő sikerül, a kliens olyan bevitelt gyűjt, amelyet semmi nem ellenőriz, és a párbeszédablakot összetévesztették egy vezérlővel. Ez az egyetlen teszt több telepítést fog meg, mint bármennyi profilmegtekintés.

Ezután ismételje meg a kapcsolatot újracsatlakozás után, egy nem regisztrált fiókkal, és azon a kliensen keresztül, amelyet a felhasználói valóban futtatnak. A felszólítás megjelenése kliensviselkedés; a rossz kód elutasítása a kiszolgáló, amely valamit kikényszerít.