Waar de statische uitdagingscode hoort bij een OpenVPN-login

De client toont een tweede vak na het wachtwoordveld, u typt de code van de hardwaretoken in, en de login mislukt nog steeds met een authenticatiefout. Dat vak bestaat, dus het profiel heeft erom gevraagd. Of de server de waarde ooit in een vorm heeft ontvangen die hij begrijpt, is een andere vraag, en die is het waard om eerst te beantwoorden.

Begin bij de prompt die uw client daadwerkelijk toont

Een profiel kan een richtlijn voor een statische uitdaging bevatten met een prompttekst en een vlag die bepaalt of het antwoord wordt weergegeven terwijl u typt. De prompt is wat u in het dialoogvenster ziet; de vlag is een weergavevoorkeur voor diezelfde invoer. Geen van beide vertelt de server hoe iets moet worden geverifieerd.

Tel de velden die u daadwerkelijk hebt gekregen. Eén veld voor een gebruikersnaam plus één gemaskeerd veld is een normale wachtwoordlogin zonder enige uitdaging. Een tweede veld dat na het wachtwoord verschijnt, met een eigen label, is de client die de uitdagingsinteractie implementeert.

Als het tweede vak nooit verschijnt in de client die u gebruikt, implementeert die client de interactie misschien niet, of alleen via een andere frontend zoals een beheerinterface. De client controleren is goedkoper dan het profiel herschrijven, en daar zit meestal de mismatch.

Wat de server al moet ondersteunen

Het profiel beschrijft wat de client moet verzamelen. Het schakelt geen verificatie op de server in, en een server zonder de bijbehorende authenticatie-integratie ontvangt gewoon een wachtwoord dat hij niet herkent. Daarom tonen sommige implementaties de prompt en weigeren ze elke code, en daarom is het antwoord van de beheerder over welk mechanisme de controle uitvoert het antwoord dat ertoe doet.

Vraag de beheerder welk mechanisme de controle uitvoert. Het kan een plug-in zijn die met PAM praat, een scripthaak die het antwoord tegen een tokendienst valideert, of een beheer-gebaseerde integratie die de verpakte waarde zelf parseert. Elk daarvan verwacht een iets andere invoer.

Hier moeten ook de verwachtingen worden gekalibreerd. Een tweede prompt is een invoermechanisme, geen bewijs dat een tweede factor wordt afgedwongen, want de handhaving gebeurt aan de serverkant en blijkt pas als u een verkeerde code test.

Het gecodeerde veld dat de beheerinterface verstuurt

Wanneer een frontend de verbinding via de beheerinterface aanstuurt, worden het wachtwoord en het uitdagingsantwoord vóór verzending in één waarde verpakt. De referentie van de beheerinterface documenteert het formaat: een voorvoegsel, dan het wachtwoord en het antwoord als afzonderlijke Base64-componenten.

Base64 is een codering, geen bescherming. Het verbergt niets voor wie het veld kan lezen, en het maakt van een eenmalige code niets herbruikbaars. De verpakte waarde verdient dezelfde behandeling als een wachtwoord: buiten gedeelde profielen, buiten commandoregels en buiten diagnostische logs.

Die codering is ook de meest voorkomende bron van verwarring, want er zijn nu drie vormen die er hetzelfde uitzien en niet uitwisselbaar zijn. Een gewoon inloggegevensbestand bevat een wachtwoord. Een letterlijke aaneenschakeling van wachtwoord en code bevat een andere tekenreeks. De verpakte reactie van een beheerclient bevat een derde. Bevestig welke uw verificatiepad verwacht voordat u een veld wijzigt alleen omdat een fout verdween.

Statisch versus dynamisch: andere timing

Een statische uitdaging is bekend voordat de eerste inloggegevens worden verzonden, dus de client kan er vooraf om vragen. Een dynamische uitdaging komt later, verzonden door de authenticatiestroom nadat een uitwisseling al is begonnen, en heeft een client nodig die een verzoek midden in het gesprek aankan.

Ondersteuning voor het ene geeft u het andere niet. Een profielrichtlijn die een statische prompt configureert, implementeert geen door de server geïnitieerde uitdaging, en een frontend die dynamische verzoeken afhandelt, toont misschien nog steeds geen statische. Lezen welke kant het verzoek begon, is de snelste manier om ze te onderscheiden.

Onafhankelijk bedrijf is waar dit een ontwerpvraag wordt in plaats van een UI-vraag. Een opgeslagen code is geen duurzame inloggegevens bij het opstarten, en een herverbinding uren later vereist nieuwe invoer, tenzij de implementatie een tokenregeling ondersteunt die de beheerder bewust heeft ingeschakeld.

Test zowel succes als falen, niet alleen de dialoog

Voer beide helften van de test uit. Juiste inloggegevens met een geldig antwoord zouden moeten slagen; juiste inloggegevens met een bewust verkeerd antwoord zouden moeten worden geweigerd. Als beide slagen, verzamelt de client invoer die niets verifieert, en is de dialoog aangezien voor een controle. Die ene test vangt meer implementaties dan enige profielbeoordeling.

Herhaal daarna de verbinding na een herverbinding, met een account dat niet is ingeschreven, en via welke client uw gebruikers ook echt gebruiken. Het verschijnen van de prompt is clientgedrag; het weigeren van een verkeerde code is de server die iets afdwingt.