OpenVPN më vonë ndërpret një sesion OTP: çfarë kërkon riautentikimi
Një sesion që vdes pas një ore është zakonisht një rindërrim çelësi që kërkon një kod të përdorur më parë. Zgjidhni midis një tokeni të lëshuar nga serveri dhe një sfide të re interaktive.
Nga ana e klientit duket si një shkëputje e rastësishme një orë pas nisjes së një sesioni pune. Ikona në tabaka zhduket, tuneli rindërtohet, dhe regjistri tregon një dështim autentikimi në vend të një gabimi rrjeti. Ajo që ndodhi në të vërtetë është se sesioni ri-negocioi dhe shtrëngimi i dytë i duarve kërkoi kredenciale për të cilat klienti nuk kishte më një kopje të vlefshme. Një kod njëpërdorimshëm që funksionoi në hyrje nuk mund të funksionojë përsëri, kështu që rindërrimi i çelësit dështon pikërisht siç është projektuar.
Zgjidhja është një vendim se çfarë duhet të paraqesë shtrëngimi i dytë i duarve, jo një kohëmatës më i gjatë riprovash.
Kaloni shkëmbimin nga këndvështrimi i klientit
Në hyrje klienti dërgon emrin e përdoruesit, fjalëkalimin dhe një kod nga pajisja token, dhe serveri e pranon kombinimin. Pastaj sesioni vazhdon derisa të aktivizohet një shkas ri-negocimi, i cili nis një shtrëngim të re duarsh TLS brenda tunelit ekzistues. Ai shtrëngim duarsh kërkon përsëri autentikim. Nëse rruga e autentikimit të serverit pret një fjalëkalim plus një kod aktual njëpërdorimshëm, klienti nuk ka kod të re për të paraqitur, përveç nëse përdoruesi është i pranishëm për ta shtypur.
Shumica e klientëve nuk hapin një kërkesë në mes të sesionit, kështu që shtrëngimi i duarve skadon dhe tuneli bie. Përdoruesi sheh një rilidhje, jo një kërkesë autentikimi, dhe për këtë arsye raporti i parë zakonisht fajëson rrjetin.
auth-gen-token ndryshon se kush përgjigjet pyetjes së dytë
Opsioni auth-gen-token i lejon serverit të lëshojë një token pas një hyrjeje të suksesshme, dhe ri-negocimet e mëvonshme paraqesin atë token në vend të përsëritjes së fjalëkalimit dhe kodit. Manuali dokumenton jetëgjatësinë dhe sjelljen e rinovimit, dhe tokeni duhet trajtuar si kredencial me skadim të vetin. Në rrugën e paracaktuar serveri e vleftëson tokenin vetë në vend që të thërrasë përsëri autentikuesin e jashtëm të fjalëkalimeve.
Me një integrim autentikimi të jashtëm, ajo ndarje ndryshon. Shtojca duhet të kuptojë gjendjen e tokenit dhe të zbatojë kontrollet e veta, sepse serveri nuk është më i vetmi komponent që vendos nëse sesioni vazhdon. Trajtimi i tokenit si një kod tjetër numerik njëpërdorimshëm nuk është zbatim i këtij funksioni.
Vendosni çfarë ndodh me statusin e llogarisë
Një token që mbijeton më shumë se aksesi i një llogarie është një vrimë në politikë. Vendosni si një llogari e çaktivizuar, një anëtarësi grupi e hequr ose një pajisje e revokuar kanë efekt ndërsa tokeni është ende i vlefshëm. Jetëgjatësi të shkurtra e zvogëlojnë dritaren; një rrugë e qartë revokimi e bën atë të qëllimshme. Shkruajeni përgjigjen para se të aktivizoni opsionin, sepse rruga e paracaktuar nuk konsulton autentikuesin e jashtëm në çdo ri-negocim.
Në një vendosje me shumë serverë, sekreti i nënshkrimit të tokenit duhet të ndahet, përndryshe klienti mund të dërgohet në një nyje që nuk mund të vleftësojë tokenin e tij.
Testoni skadimin dhe rilidhjen, jo vetëm hyrjen
Zvogëloni intervalin e ri-negocimit në një profil testimi që shtrëngimi i dytë i duarve të ndodhë ndërsa po shikoni, pastaj ndiqni të dy regjistrat. Konfirmoni që tokeni lëshohet në hyrje, paraqitet në rindërrimin e çelësit dhe rinovohet ose rilëshohet sipas jetëgjatësisë së konfiguruar. Pastaj impononi skadimin e tokenit dhe një rilidhje të plotë, sepse një klient që rilidhet pastër mund të dështojë ende në rrugën e rindërrimit të çelësit.
Testoni heqjen e llogarisë në fund. Ai rast ju tregon nëse politika që shkruat zbatohet apo thjesht dokumentohet.
Mos e rregulloni duke çaktivizuar rinovimin
Vendosja e intervalit të ri-negocimit në zero në të dyja palët heq simptomën dhe bashkë me të rrotullimin e çelësave. Kjo fsheh një problem të ripërdorimit të kredencialeve pas një ndryshimi politike që askush nuk e shqyrtoi. Mbani rinovimin dhe zgjidhni midis një tokeni të lëshuar nga serveri dhe një sfide të re interaktive sipas faktit nëse një përdorues është i pranishëm.
Një kohëmatës më i gjatë riprovash nuk e bën përsëri të vlefshëm një kod të shpenzuar. Ai vetëm e vonon shkëputjen dhe e bën regjistrin më të vështirë për t'u lexuar.