Hvor den statiske utfordringskoden hører hjemme i en OpenVPN-innlogging

Klienten viser en annen boks etter passordfeltet, du skriver inn koden fra jernvaretokenet, og innloggingen feiler fortsatt med en autentiseringsfeil. Den boksen finnes, så profilen ba om den. Om serveren noen gang mottok verdien i en form den forstår, er et annet spørsmål, og det er det som er verdt å svare på først.

Start med ledeteksten klienten din faktisk viser

En profil kan inneholde et direktiv for statisk utfordring med en ledetekststreng og et flagg som styrer om svaret vises mens du skriver. Ledeteksten er det du ser i dialogen; flagget er en visningsinnstilling for den samme inndataen. Ingen av dem forteller serveren hvordan den skal verifisere noe.

Tell feltene du faktisk fikk. Ett felt for et brukernavn pluss ett maskert felt er en vanlig passordinnlogging helt uten utfordring. Et andre felt som dukker opp etter passordet, med sin egen etikett, er klienten som implementerer utfordringsinteraksjonen.

Hvis den andre boksen aldri vises i klienten du bruker, implementerer den kanskje ikke interaksjonen, eller den implementerer den bare gjennom en annen frontend som et administrasjonsgrensesnitt. Å sjekke klienten er billigere enn å skrive om profilen, og det er vanligvis der avviket faktisk ligger.

Hva serveren allerede må støtte

Profilen beskriver hva klienten skal samle inn. Den aktiverer ikke verifisering på serveren, og en server uten den tilsvarende autentiseringsintegrasjonen vil bare motta et passord den ikke kjenner igjen. Derfor viser noen installasjoner ledeteksten og avviser hver kode, og derfor er operatørens svar på hvilken mekanisme som utfører kontrollen det svaret som betyr noe.

Spør operatøren hvilken mekanisme som utfører kontrollen. Det kan være et plugin som snakker med PAM, en skriptkrok som validerer svaret mot en tokentjeneste, eller en administrasjonsbasert integrasjon som selv parser den pakkede verdien. Hver av dem forventer litt ulik inndata.

Her må også forventningene kalibreres. En andre ledetekst er en inndatamekanisme, ikke bevis for at en andre faktor håndheves, fordi håndhevelsen skjer på serversiden og først vises når du tester en feil kode.

Det kodede feltet som administrasjonsgrensesnittet sender

Når en frontend driver forbindelsen gjennom administrasjonsgrensesnittet, pakkes passordet og utfordringssvaret i én verdi før innsending. Referansen for administrasjonsgrensesnittet dokumenterer formatet: et prefiks, deretter passordet og svaret som separate Base64-komponenter.

Base64 er en koding, ikke en beskyttelse. Den skjuler ingenting for noen som kan lese feltet, og den gjør ikke en engangskode om til noe gjenbrukbart. Den pakkede verdien fortjener samme behandling som et passord: ut av delte profiler, ut av kommandolinjer og ut av diagnostiske logger.

Den kodingen er også den vanligste kilden til forvirring, fordi det nå finnes tre former som ser like ut og ikke kan byttes om. En vanlig legitimasjonsfil inneholder et passord. En bokstavelig sammenslåing av passord og kode inneholder en annen streng. En administrasjonsklients pakkede svar inneholder en tredje. Bekreft hvilken verifiseringsveien din forventer før du endrer et felt bare fordi en feil forsvant.

Statisk kontra dynamisk: ulik timing

En statisk utfordring er kjent før den første legitimasjonen sendes, så klienten kan spørre om den på forhånd. En dynamisk utfordring kommer senere, sendt av autentiseringsflyten etter at en utveksling allerede er begynt, og den trenger en klient som kan håndtere en forespørsel midt i samtalen.

Støtte for den ene gir deg ikke den andre. Et profildirektiv som konfigurerer en statisk ledetekst, implementerer ikke en serverinitiert utfordring, og en frontend som håndterer dynamiske forespørsler viser kanskje fortsatt ikke en statisk. Å lese hvilken side som startet forespørselen er den raskeste måten å skille dem.

Uovervåket drift er der dette blir et designspørsmål snarere enn et UI-spørsmål. En lagret kode er ikke en varig legitimasjon ved oppstart, og en gjenoppkobling timer senere trenger fersk inndata med mindre installasjonen støtter en tokenordning som operatøren bevisst har slått på.

Test både suksess og feil, ikke bare dialogen

Kjør begge halvdeler av testen. Riktig legitimasjon med et gyldig svar bør lykkes; riktig legitimasjon med et bevisst feil svar bør avvises. Hvis begge lykkes, samler klienten inndata som ingenting verifiserer, og dialogen er blitt forvekslet med en kontroll. Den ene testen fanger flere installasjoner enn noen mengde profilgjennomgang.

Gjenta deretter forbindelsen etter en gjenoppkobling, med en konto som ikke er registrert, og gjennom hvilken som helst klient brukerne dine faktisk kjører. At ledeteksten vises, er klientatferd; at en feil kode avvises, er serveren som håndhever noe.