Az OpenVPN később eldob egy OTP-munkamenetet: mire van szüksége az újrahitelesítésnek
Az egy óra után elhaló munkamenet általában kulcsújítás, amely már használt kódot kér. Válasszon a kiszolgáló által kibocsátott token és egy friss interaktív kihívás között.
Ügyféloldalról úgy tűnik, mintha egy működő munkamenet egy órája után véletlenszerűen megszakadna a kapcsolat. A tálcán lévő ikon eltűnik, az alagút újraépül, és a napló hitelesítési hibát mutat hálózati hiba helyett. Valójában a munkamenet újratárgyalta a kapcsolatot, és a második kézfogásnak olyan hitelesítő adatokra volt szüksége, amelyeknek az ügyfél már nem rendelkezett érvényes példányával. Az egyszeri kód, amely a bejelentkezésnél működött, nem működhet újra, ezért a kulcsújítás pontosan a tervezés szerint hiúsul meg.
A javítás döntés arról, mit mutasson be a második kézfogás, nem hosszabb újrapróbálkozási időzítő.
Kövesse végig a cserét az ügyfél szemszögéből
Bejelentkezéskor az ügyfél elküldi a felhasználónevet, a jelszót és a tokeneszköz kódját, a kiszolgáló pedig elfogadja a kombinációt. Ezután a munkamenet addig fut, amíg be nem indul egy újratárgyalási esemény, amely új TLS-kézfogást indít a meglévő alagúton belül. Ez a kézfogás újra hitelesítést kér. Ha a kiszolgáló hitelesítési útvonala jelszót és aktuális egyszeri kódot vár, az ügyfélnek nincs új kódja, hacsak a felhasználó nincs jelen, hogy beírjon egyet.
A legtöbb ügyfél nem nyit felkérést a munkamenet közepén, ezért a kézfogás lejár, és az alagút megszakad. A felhasználó újracsatlakozást lát, nem hitelesítési felkérést, és ezért a legelső jelentés általában a hálózatot hibáztatja.
Az auth-gen-token megváltoztatja, ki válaszol a második kérdésre
auth-gen-token az a beállítás, amely engedi, hogy a kiszolgáló sikeres bejelentkezés után tokent bocsásson ki, és a későbbi újratárgyalások ezt a tokent mutatják be a jelszó és a kód ismétlése helyett. A kézikönyv dokumentálja annak élettartamát és megújítási viselkedését, és a tokent saját lejárattal rendelkező hitelesítő adatként kell kezelni. Az alapértelmezett útvonalon a kiszolgáló maga ellenőrzi a tokent ahelyett, hogy újra hívná a külső jelszó-hitelesítőt.
Külső hitelesítési integrációval ez a felosztás megváltozik. A beépülőnek meg kell értenie a token állapotát, és saját ellenőrzéseket kell alkalmaznia, mert a kiszolgáló már nem az egyetlen összetevő, amely eldönti, folytatódik-e a munkamenet. A tokent újabb numerikus egyszeri kódként kezelni nem e funkció megvalósítása.
Döntse el, mi történik a fiók állapotával
A fiók hozzáférését túlélő token kiskapu a szabályzatban. Döntse el, hogyan lép életbe egy letiltott fiók, egy eltávolított csoporttagság vagy egy visszavont eszköz, miközben a token még érvényes. A rövid token-élettartamok szűkítik az ablakot; egy kifejezett visszavonási útvonal szándékossá teszi. Írja le a választ a beállítás engedélyezése előtt, mert az alapértelmezett útvonal nem kérdez rá a külső hitelesítőre minden újratárgyalásnál.
Többkiszolgálós telepítésnél a token-aláírási titkot meg kell osztani, különben az ügyfél olyan csomópontra kerülhet, amely nem tudja ellenőrizni a tokenjét.
A lejárást és az újracsatlakozást tesztelje, ne csak a bejelentkezést
Csökkentse az újratárgyalási időközt egy tesztprofilban, hogy a második kézfogás a szeme láttára történjen meg, majd kövesse mindkét naplót. Erősítse meg, hogy a token bejelentkezéskor kibocsátódik, kulcsújításkor bemutatásra kerül, és a beállított élettartam szerint megújul vagy újra kibocsátódik. Ezután kényszerítsen ki egy token-lejáratot és egy teljes újracsatlakozást, mert a tisztán újracsatlakozó ügyfél a kulcsújítási útvonalon még mindig elbukhat.
A fiók eltávolítását utoljára tesztelje. Ez az eset megmondja, hogy az írott szabályzat érvényesül-e, vagy csak dokumentálva van.
Ne javítsa a megújítás kikapcsolásával
Az újratárgyalási időköz nullára állítása mindkét oldalon megszünteti a tünetet és vele a kulcsrotációt. Ez elrejti a hitelesítő adatok újrafelhasználásának problémáját egy olyan szabályzatváltozás mögé, amelyet senki nem nézett át. Tartsa meg a megújítást, és a felhasználó jelenléte alapján válasszon a kiszolgáló által kibocsátott token és egy friss interaktív kihívás között.
A hosszabb újrapróbálkozási időzítő nem teszi újra érvényessé az elhasznált kódot. Csak késlelteti a megszakadást, és nehezebbé teszi a napló olvasását.