Sa strane klijenta to izgleda kao slučajan prekid sat vremena nakon radne sesije. Ikona u traci nestaje, tunel se ponovo gradi, a zapisnik pokazuje grešku autentifikacije, a ne mrežnu grešku. Zapravo se sesija ponovo pregovarala i drugo rukovanje je zahtijevalo vjerodajnice čiju valjanu kopiju klijent više nije imao. Jednokratni kod koji je radio pri prijavi ne može ponovo raditi, pa obnavljanje ključa pada tačno kako je projektovano.

Rješenje je odluka o tome šta drugo rukovanje treba predstaviti, a ne duži tajmer ponovnog pokušaja.

Pratite razmjenu iz ugla klijenta

Pri prijavi klijent šalje korisničko ime, lozinku i kod s token uređaja, a server prihvata tu kombinaciju. Sesija zatim radi dok se ne aktivira okidač ponovnog pregovaranja, koji pokreće novo TLS rukovanje unutar postojećeg tunela. To rukovanje ponovo traži autentifikaciju. Ako put autentifikacije na serveru očekuje lozinku plus aktuelni jednokratni kod, klijent nema novi kod da ponudi osim ako korisnik nije prisutan da ga otkuca.

Većina klijenata ne otvara upit usred sesije, pa rukovanje istekne i tunel padne. Korisnik vidi ponovno povezivanje, a ne upit za autentifikaciju, i zato prvi izvještaj obično krivi mrežu.

auth-gen-token mijenja ko odgovara na drugo pitanje

auth-gen-token je opcija koja omogućava serveru da izda token nakon uspješne prijave, a kasnija ponovna pregovaranja predstavljaju taj token umjesto ponavljanja lozinke i koda. Priručnik dokumentuje njegov životni vijek i ponašanje pri obnavljanju, a token se mora tretirati kao vjerodajnica s vlastitim rokom trajanja. Na podrazumijevanom putu server sam provjerava token umjesto da ponovo poziva vanjski autentifikator lozinke.

S vanjskom integracijom autentifikacije ta podjela se mijenja. Dodatak mora razumjeti stanje tokena i primjenjivati vlastite provjere, jer server više nije jedina komponenta koja odlučuje da li se sesija nastavlja. Tretiranje tokena kao još jednog numeričkog jednokratnog koda nije implementacija te funkcije.

Odlučite šta se dešava sa statusom računa

Token koji nadživi pristup računu je rupa u politici. Odlučite kako deaktiviran račun, uklonjeno članstvo u grupi ili opozvan uređaj stupaju na snagu dok je token još valjan. Kratki životni vijek tokena smanjuje prozor; jasan put opoziva čini ga namjernim. Zapišite odgovor prije nego što uključite opciju, jer podrazumijevani put ne konsultuje vanjski autentifikator pri svakom ponovnom pregovaranju.

U rasporedu s više servera, tajna za potpisivanje tokena mora biti dijeljena, inače klijent može biti poslan na čvor koji ne može provjeriti njegov token.

Testirajte istek i ponovno povezivanje, ne samo prijavu

Smanjite interval ponovnog pregovaranja u testnom profilu da se drugo rukovanje dogodi dok gledate, pa pratite oba zapisa. Potvrdite da se token izdaje pri prijavi, predstavlja pri obnavljanju ključa i osvježava ili ponovo izdaje prema konfigurisanom životnom vijeku. Zatim izazovite istek tokena i potpuno ponovno povezivanje, jer klijent koji se čisto poveže i dalje može pasti na putu obnavljanja ključa.

Testirajte uklanjanje računa posljednje. Taj slučaj vam kaže da li se politika koju ste napisali provodi ili je samo dokumentovana.

Ne popravljajte to isključivanjem obnavljanja

Postavljanje intervala ponovnog pregovaranja na nulu na obje strane uklanja simptom i rotaciju ključeva s njim. Time se problem ponovne upotrebe vjerodajnica skriva iza promjene politike koju niko nije pregledao. Zadržite obnavljanje i birajte između tokena koji izdaje server i svježeg interaktivnog izazova na osnovu toga da li je korisnik prisutan.

Duži tajmer ponovnog pokušaja ne čini iskorišteni kod ponovo valjanim. On samo odgađa prekid i čini zapisnik težim za čitanje.

Povezani članci