Wêr't de statyske útdagingskoade yn in OpenVPN-oanmelding heart

De kliïnt lit in twadde fak sjen nei it wachtwurdfjild, jo type it koad fan it hardwaretoken yn, en de oanmelding mislearret noch altyd mei in autentikaasjeflater. Dat fak bestiet, dus it profyl hat derom frege. Oft de tsjinner de wearde ea yn in foarm krigen hat dy't er begrypt, is in oare fraach, en dy is it wurdich om earst te beäntwurdzjen.

Begjin by de oanwizing dy't jo kliïnt eins sjen lit

In profyl kin in statyske útdagingsdirektive drage mei in oanwizingstekst en in flagge dy't regelet oft it antwurd sjen litten wurdt wylst jo type. De oanwizing is wat jo yn de dialooch sjogge; de flagge is in werjaflike foarkar foar deselde ynfier. Gjin fan beide fertelt de tsjinner hoe't er eat ferifiearje moat.

Tel de fjilden dy't jo eins krigen hawwe. Ien fjild foar in brûkersnamme plus ien maskearre fjild is in gewoane wachtwurdoanmelding sûnder hokker útdaging dan ek. In twadde fjild dat nei it wachtwurd ferskynt, mei syn eigen label, is de kliïnt dy't de útdagingsynteraksje ymplementearret.

As it twadde fak nea ferskynt yn de kliïnt dy't jo brûke, ymplementearret dy kliïnt de ynteraksje miskien net, of docht er dat allinnich fia in oare foarkant lykas in behearinterface. It kontrolearjen fan de kliïnt is goedkeaper as it wer oerskriuwen fan it profyl, en meastentiids sit dêr echt de mismatch.

Wat de tsjinner al stypje moat

It profyl beskriuwt wat de kliïnt sammelje moat. It skeakelet gjin ferifikaasje op de tsjinner yn, en in tsjinner sûnder de oangeande autentikaasje-ynbouding sil gewoan in wachtwurd krije dat er net ken. Dat is wêrom't guon ymplemintaasjes de oanwizing sjen litte en elk koad ôfwize, en wêrom't it antwurd fan de operator oer hokker meganisme de kontrôle docht it antwurd is dat der ta docht.

Freegje de operator hokker meganisme de kontrôle docht. It kin in plug-in wêze dy't mei PAM praat, in skripthaak dy't it antwurd tsjin in tokentsjinst falidearret, of in behear-basearre ynbouding dy't de ferpakte wearde sels ûntleedt. Elk fan dy ferwachtet in bytsje oare ynfier.

Hjir moatte ek de ferwachtings kalibrearre wurde. In twadde oanwizing is in ynfiermeganisme, gjin bewiis dat in twadde faktor útoefene wurdt, want de útoefening bart oan de tsjinnerkant en lit him pas sjen as jo in ferkeard koad testen.

It kodearre fjild dat de behearinterface stjoert

As in foarkant de ferbining fia de behearinterface oanstjoert, wurde it wachtwurd en it útdagingsantwurd foar it ferstjoeren yn ien wearde ferpakt. De referinsje fan de behearinterface dokumintearret it formaat: in prefix, en dêrnei it wachtwurd en it antwurd as aparte Base64-komponinten.

Base64 is in kodearring, gjin beskerming. It ferberget neat foar wa't it fjild lêze kin, en it makket fan in ienmalich koad neat werbrûkbers. De ferpakte wearde fertsjinnet deselde behanneling as in wachtwurd: bûten dielde profylen, bûten kommandorigels en bûten diagnostyske logs.

Dy kodearring is ek de meast foarkommende boarne fan betizing, want der binne no trije foarmen dy't op inoar lykje en net útwikselber binne. In gewoan oanmeldbestân hâldt in wachtwurd. In letterlike gearfoeging fan wachtwurd en koad hâldt in oare string. De ferpakte antwurd fan in behearder-kliïnt hâldt in tredde. Befestigje hokker jo ferifikaasjepaad ferwachtet foardat jo in fjild feroarje, allinnich om't in flater fuort wie.

Statysk tsjin dynamysk: oare timing

In statyske útdaging is bekend foardat de earste oanmeldgegevens ferstjoerd wurde, sadat de kliïnt der foarôf om freegje kin. In dynamyske útdaging komt letter, stjoerd troch de autentikaasjewurkstream neidat in útwikseling al begûn is, en hy freget in kliïnt dy't in fersyk midden yn it petear oan kin.

Stypje foar ien jout jo de oare net. In profyldirektive dy't in statyske oanwizing konfigurearret, ymplementearret gjin útdaging dy't troch de tsjinner start is, en in foarkant dy't dynamyske fersiken oan kin, lit miskien noch altyd gjin statyske sjen. Lêze hokker kant it fersyk start hat, is de fluchste manier om se te ûnderskieden.

Unbeheind betsjinjen is wêr't dit in ûntwerpfraach wurdt yn stee fan in interfacefraach. In bewarre koad is gjin duorsume oanmeldgegevens by it opstarten, en in werferbining oeren letter hat frisse ynfier nedich, útsein as de ymplemintaasje in tokenregeling stipet dy't de operator bewust ynskeakele hat.

Test sukses en mislearring, net allinnich de dialooch

Fier beide helten fan de test út. Krekte oanmeldgegevens mei in jildich antwurd hearre te slagjen; krekte oanmeldgegevens mei in bewust ferkeard antwurd hearre wegere te wurden. As beide slagje, sammelt de kliïnt ynfier dy't neat ferifiearret, en de dialooch is foar in kontrôle oansjoen. Dy iene test fangt mear ymplemintaasjes as hokker hoemannichte profylresinsje dan ek.

Werhelje dan de ferbining nei in werferbining, mei in akkount dat net ynskreaun is, en fia hokker kliïnt jo brûkers eins ek brûke. It ferskinen fan 'e oanwizing is kliïntgedrach; it ôfwizen fan in ferkeard koad is de tsjinner dy't eat útoefenet.