OpenVPN kobler ned en OTP-økt senere: hva reautentisering krever

Fra klientens side ser det ut som en tilfeldig frakobling en time ut i en arbeidsøkt. Skuffikonet forsvinner, tunnelen bygges opp igjen, og loggen viser en autentiseringsfeil i stedet for en nettverksfeil. Det som faktisk skjedde, var at økten reforhandlet og at den andre håndtrykken trengte legitimasjon som klienten ikke lenger hadde en gyldig kopi av. En engangskode som fungerte ved innlogging kan ikke fungere igjen, så rekeyen feiler nøyaktig som designet.

Løsningen er en beslutning om hva den andre håndtrykken skal presentere, ikke en lengre retry-timer.

Gå gjennom utvekslingen fra klientens ståsted

Ved innlogging sender klienten brukernavnet, passordet og en kode fra tokenenheten, og serveren godtar kombinasjonen. Deretter går økten til en utløser for reforhandling fyrer av, og den starter en ny TLS-håndtrykk inne i den eksisterende tunnelen. Den håndtrykken ber om autentisering på nytt. Hvis serverens autentiseringsvei forventer et passord pluss en gjeldende engangskode, har klienten ingen ny kode å tilby med mindre brukeren er til stede og kan skrive den inn.

De fleste klienter åpner ikke en forespørsel midt i økten, så håndtrykken går ut på tid og tunnelen faller. Brukeren ser en tilkobling på nytt, ikke en autentiseringsforespørsel, og derfor legger den første rapporten vanligvis skylden på nettverket.

auth-gen-token endrer hvem som svarer på det andre spørsmålet

Alternativet auth-gen-token lar serveren utstede et token etter vellykket innlogging, og senere reforhandlinger presenterer det tokenet i stedet for å gjenta passordet og koden. Håndboken dokumenterer levetiden og fornyelsesatferden, og tokenet må behandles som legitimasjon med sin egen utløpsdato. I standardveien validerer serveren tokenet selv i stedet for å kalle den eksterne passordautentikatoren på nytt.

Med en ekstern autentiseringsintegrasjon endres den fordelingen. Pluginen må forstå tokenets tilstand og bruke sine egne kontroller, fordi serveren ikke lenger er den eneste komponenten som avgjør om økten fortsetter. Å behandle tokenet som nok en numerisk engangskode er ikke en implementering av funksjonen.

Bestem hva som skjer med kontostatusen

Et token som lever lenger enn en kontos tilgang er et hull i policyen. Bestem hvordan en deaktivert konto, et fjernet gruppemedlemskap eller en tilbakekalt enhet virker mens et token fortsatt er gyldig. Kort tokenlevetid gjør vinduet mindre; en eksplisitt tilbakekallingsvei gjør det bevisst. Skriv ned svaret før du aktiverer alternativet, fordi standardveien ikke spør den eksterne autentikatoren ved hver reforhandling.

I en distribusjon med flere servere må hemmeligheten for tokensignering deles, ellers kan klienten sendes til en node som ikke kan validere tokenet.

Test utløp og gjenoppkobling, ikke bare innlogging

Senk reforhandlingsintervallet i en testprofil slik at den andre håndtrykken skjer mens du ser på, og følg deretter begge loggene. Bekreft at tokenet utstedes ved innlogging, presenteres ved rekey, og fornyes eller utstedes på nytt i henhold til den konfigurerte levetiden. Tving deretter frem et tokenutløp og en full gjenoppkobling, fordi en klient som kobler til på nytt rent fortsatt kan feile på rekey-veien.

Test kontofjerning til slutt. Det tilfellet forteller deg om policyen du skrev håndheves eller bare dokumenteres.

Ikke fiks det ved å slå av fornyelse

Å sette reforhandlingsintervallet til null på begge parter fjerner symptomet og nøkkelrotasjonen med det. Det skjuler et problem med gjenbruk av legitimasjon bak en policyendring ingen har gjennomgått. Behold fornyelsen, og velg mellom et token utstedt av serveren og en ny interaktiv utfordring basert på om en bruker er til stede.

En lengre retry-timer gjør ikke en brukt kode gyldig igjen. Den bare utsetter frakoblingen og gjør loggen vanskeligere å lese.