Kvar den statiske utfordringskoden høyrer heime i ei OpenVPN-innlogging

Klienten viser ein annan boks etter passordfeltet, du skriv inn koden frå jarnvaretokenet, og innlogginga feilar framleis med ein autentiseringsfeil. Den boksen finst, så profilen bad om han. Om serveren nokon gong fekk verdien i ei form han forstår, er eit anna spørsmål, og det er det som er verdt å svare på først.

Start med leieteksten klienten din faktisk viser

Ein profil kan innehalde eit direktiv for statisk utfordring med ein leietekststreng og eit flagg som styrer om svaret blir vist medan du skriv. Leieteksten er det du ser i dialogen; flagget er ei visingsinnstilling for den same inndataa. Ingen av dei fortel serveren korleis noko skal verifiserast.

Tel felta du faktisk fekk. Eitt felt for eit brukarnamn pluss eitt maskert felt er ei vanleg passordinnlogging heilt utan utfordring. Eit andre felt som dukkar opp etter passordet, med si eiga etikett, er klienten som implementerer utfordringsinteraksjonen.

Viss den andre boksen aldri blir vist i klienten du brukar, implementerer han kanskje ikkje interaksjonen, eller berre gjennom ein annan frontend som eit administrasjonsgrensesnitt. Å sjekke klienten er billegare enn å skrive om profilen, og det er vanlegvis der avviket faktisk ligg.

Kva serveren allereie må støtte

Profilen skildrar kva klienten skal samle inn. Han slår ikkje på verifisering på serveren, og ein server utan den tilsvarande autentiseringsintegrasjonen vil berre få eit passord han ikkje kjenner att. Difor viser nokre installasjonar leieteksten og avviser kvar kode, og difor er svaret til operatøren om kva mekanisme som gjer kontrollen det svaret som betyr noko.

Spør operatøren kva mekanisme som gjer kontrollen. Det kan vere eit programtillegg som snakkar med PAM, ein skriptkrok som validerer svaret mot ein tenesteleverandør for token, eller ein administrasjonsbasert integrasjon som sjølv tolkar den pakka verdien. Kvar av dei ventar litt ulik inndata.

Her må òg forventningane kalibrerast. Ein andre leietekst er ein inndatamekanisme, ikkje prov på at ein andre faktor blir handheva, fordi handhevinga skjer på serversida og først blir synleg når du testar ein feil kode.

Det koda feltet som administrasjonsgrensesnittet sender

Når ein frontend driv sambandet gjennom administrasjonsgrensesnittet, blir passordet og utfordringssvaret pakka i éin verdi før innsending. Referansen for administrasjonsgrensesnittet dokumenterer formatet: eit prefiks, deretter passordet og svaret som separate Base64-komponentar.

Base64 er ei koding, ikkje ei vern. Ho gøymer ingenting for nokon som kan lese feltet, og ho gjer ikkje ein eingongskode om til noko gjenbrukbart. Den pakka verdien fortener same handsaming som eit passord: ut av delte profilar, ut av kommandolinjer og ut av diagnostiske loggar.

Den kodinga er òg den vanlegaste kjelda til forvirring, fordi det no finst tre former som ser like ut og ikkje kan bytast om. Ei vanleg legitimasjonsfil inneheld eit passord. Ei bokstavleg samanslåing av passord og kode inneheld ein annan streng. Eit pakka svar frå ein administrasjonsklient inneheld ein tredje. Stadfest kva verifiseringsvegen din ventar før du endrar eit felt berre fordi ein feil forsvann.

Statisk kontra dynamisk: ulik timing

Ei statisk utfordring er kjend før den første legitimasjonen blir send, så klienten kan spørje om ho på førehand. Ei dynamisk utfordring kjem seinare, send av autentiseringsflyten etter at ei utveksling allereie er byrja, og ho treng ein klient som kan handsame ein førespurnad midt i samtalen.

Støtte for den eine gir deg ikkje den andre. Eit profildirektiv som set opp ein statisk leietekst, implementerer ikkje ei serverinitiert utfordring, og ein frontend som handsamar dynamiske førespurnader viser kanskje framleis ikkje ein statisk. Å lese kva side som starta førespurnaden er den raskaste måten å skilje dei.

Uovervaka drift er der dette blir eit designspørsmål snarare enn eit UI-spørsmål. Ein lagra kode er ikkje ein varig legitimasjon ved oppstart, og ei gjenoppkopling timar seinare treng fersk inndata med mindre installasjonen støttar ei tokenordning som operatøren medvite har slått på.

Test både suksess og feil, ikkje berre dialogen

Køyr begge halvdelane av testen. Riktig legitimasjon med eit gyldig svar bør lukkast; riktig legitimasjon med eit medvite feil svar bør avvisast. Viss begge lukkast, samlar klienten inndata som ingenting verifiserer, og dialogen er blitt forveksla med ein kontroll. Den eine testen fangar fleire installasjonar enn noka mengd profilgjennomgang.

Gjenta deretter sambandet etter ei gjenoppkopling, med ein konto som ikkje er registrert, og gjennom kva klient brukarane dine faktisk køyrer. At leieteksten blir vist, er klientåtferd; at ein feil kode blir avvist, er serveren som handhevar noko.