Var den statiska utmaningskoden hör hemma i en OpenVPN-inloggning

Klienten visar en andra ruta efter lösenordsfältet, du skriver in koden från hårdvarutokenet, och inloggningen misslyckas fortfarande med ett autentiseringsfel. Den rutan finns, så profilen bad om den. Om servern någonsin tog emot värdet i en form den förstår är en annan fråga, och det är den som är värd att svara på först.

Börja med den uppmaning som din klient faktiskt visar

En profil kan bära ett direktiv för statisk utmaning med en uppmaningstext och en flagga som styr om svaret visas medan du skriver. Uppmaningen är det du ser i dialogrutan; flaggan är en visningsinställning för samma inmatning. Ingen av dem berättar för servern hur något ska verifieras.

Räkna fälten du faktiskt fick. Ett fält för ett användarnamn plus ett maskerat fält är en vanlig lösenordsinloggning helt utan utmaning. Ett andra fält som dyker upp efter lösenordet, med en egen etikett, är klienten som implementerar utmaningsinteraktionen.

Om den andra rutan aldrig visas i klienten du använder implementerar den kanske inte interaktionen, eller bara genom ett annat gränssnitt som ett administrationsgränssnitt. Att kontrollera klienten är billigare än att skriva om profilen, och det är oftast där avvikelsen faktiskt ligger.

Vad servern redan måste stödja

Profilen beskriver vad klienten ska samla in. Den aktiverar inte verifiering på servern, och en server utan motsvarande autentiseringsintegration tar helt enkelt emot ett lösenord den inte känner igen. Därför visar vissa installationer uppmaningen och avvisar varje kod, och därför är operatörens svar om vilken mekanism som utför kontrollen det svar som spelar roll.

Fråga operatören vilken mekanism som utför kontrollen. Det kan vara ett plugin som talar med PAM, en skriptkrok som validerar svaret mot en tokentjänst, eller en administrationsbaserad integration som själv tolkar det packade värdet. Var och en av dem förväntar sig en något annan inmatning.

Här måste även förväntningarna kalibreras. En andra uppmaning är en inmatningsmekanism, inte bevis på att en andra faktor tillämpas, eftersom tillämpningen sker på serversidan och bara syns när du testar en felaktig kod.

Det kodade fältet som administrationsgränssnittet skickar

När ett gränssnitt driver anslutningen genom administrationsgränssnittet packas lösenordet och utmaningssvaret i ett enda värde före sändning. Referensen för administrationsgränssnittet dokumenterar formatet: ett prefix, därefter lösenordet och svaret som separata Base64-komponenter.

Base64 är en kodning, inte ett skydd. Den döljer ingenting för den som kan läsa fältet, och den gör inte en engångskod till något återanvändbart. Det packade värdet förtjänar samma behandling som ett lösenord: ut ur delade profiler, ut ur kommandorader och ut ur diagnostikloggar.

Den kodningen är också den vanligaste källan till förvirring, eftersom det nu finns tre former som ser likadana ut och inte är utbytbara. En vanlig autentiseringsfil innehåller ett lösenord. En bokstavlig sammanfogning av lösenord och kod innehåller en annan sträng. En administrationsklients packade svar innehåller en tredje. Bekräfta vilken din verifieringsväg förväntar sig innan du ändrar ett fält bara för att ett fel försvann.

Statisk kontra dynamisk: olika timing

En statisk utmaning är känd innan den första autentiseringsuppgiften skickas, så klienten kan fråga efter den i förväg. En dynamisk utmaning kommer senare, skickad av autentiseringsflödet efter att ett utbyte redan börjat, och den kräver en klient som kan hantera en begäran mitt i samtalet.

Stöd för den ena ger dig inte den andra. Ett profildirektiv som konfigurerar en statisk uppmaning implementerar inte en serverinitierad utmaning, och ett gränssnitt som hanterar dynamiska begäranden kanske fortfarande inte visar en statisk. Att läsa vilken sida som initierade begäran är det snabbaste sättet att skilja dem åt.

Oövervakad drift är där detta blir en designfråga snarare än en gränssnittsfråga. En sparad kod är inte en varaktig autentiseringsuppgift vid start, och en återanslutning timmar senare kräver ny inmatning om inte installationen stöder ett tokenarrangemang som operatören medvetet har aktiverat.

Testa både framgång och misslyckande, inte bara dialogrutan

Kör båda halvorna av testet. Korrekta autentiseringsuppgifter med ett giltigt svar bör lyckas; korrekta autentiseringsuppgifter med ett avsiktligt felaktigt svar bör avvisas. Om båda lyckas samlar klienten in inmatning som ingenting verifierar, och dialogrutan har förväxlats med en kontroll. Det enda testet fångar fler installationer än någon mängd profilgranskning.

Upprepa sedan anslutningen efter en återanslutning, med ett konto som inte är registrerat, och genom vilken klient dina användare faktiskt kör. Att uppmaningen visas är klientbeteende; att en felaktig kod avvisas är servern som genomdriver något.