Waar die statiese uitdagingskode in 'n OpenVPN-aanmelding beland

Die kliënt wys 'n tweede blokkie ná die wagwoordveld, jy tik die kode van die hardeware-token in, en die aanmelding misluk steeds met 'n verifikasiëfout. Daardie blokkie bestaan, dus het die profiel daarvoor gevra. Of die bediener die waarde ooit in 'n vorm ontvang het wat hy verstaan, is 'n ander vraag, en dit is die een wat eerste beantwoord moet word.

Begin by die opdragteks wat jou kliënt werklik wys

'n Profiel kan 'n statiese uitdagingsopdrag dra met 'n opdragteks en 'n vlag wat bepaal of die antwoord vertoon word terwyl jy tik. Die opdragteks is wat jy in die dialoog sien; die vlag is 'n vertoonvoorkeur vir daardie selfde invoer. Nie een van hulle sê vir die bediener hoe om enigiets te verifieer nie.

Tel die velde wat jy werklik gekry het. Een veld vir 'n gebruikersnaam plus een gemaskeerde veld is 'n gewone wagwoordaanmelding sonder enige uitdaging. 'n Tweede veld wat ná die wagwoord verskyn, met sy eie etiket, is die kliënt wat die uitdagingsinteraksie implementeer.

As die tweede blokkie nooit in die kliënt verskyn wat jy gebruik nie, implementeer daardie kliënt dalk nie die interaksie nie, of hy implementeer dit dalk net deur 'n ander voorkant soos 'n bestuurskoppelvlak. Om die kliënt na te gaan is goedkoper as om die profiel te herskryf, en dit is gewoonlik waar die wanverhouding werklik sit.

Wat die bediener reeds moet ondersteun

Die profiel beskryf wat die kliënt moet insamel. Dit aktiveer nie verifiëring op die bediener nie, en 'n bediener sonder die ooreenstemmende verifikasiëintegrasie sal bloot 'n wagwoord ontvang wat hy nie herken nie. Dit is waarom sommige ontplooiings die opdragteks wys en elke kode verwerp, en waarom die operateur se antwoord oor watter meganisme die kontrole doen, die een is wat saak maak.

Vra die operateur watter meganisme die kontrole doen. Dit kan 'n inprop wees wat met PAM praat, 'n script-haak wat die antwoord teen 'n tokendiens valideer, of 'n bestuursgebaseerde integrasie wat die ingepakte waarde self ontleed. Elkeen van dié verwag 'n effens ander invoer.

Dit is ook waar verwagtinge gekalibreer moet word. 'n Tweede opdragteks is 'n invoermeganisme, nie 'n bewys dat 'n tweede faktor afgedwing word nie, want afdwinging gebeur aan die bedienerkant en wys eers wanneer jy 'n verkeerde kode toets.

Die geënkodeerde veld wat die bestuurskoppelvlak stuur

Wanneer 'n voorkant die verbinding deur die bestuurskoppelvlak dryf, word die wagwoord en die uitdagingsantwoord voor indiening in 'n enkele waarde ingepak. Die verwysing vir die bestuurskoppelvlak dokumenteer die formaat: 'n voorvoegsel, dan die wagwoord en die antwoord as aparte Base64-komponente.

Base64 is 'n enkodering, nie 'n beskerming nie. Dit verberg niks vir enigiemand wat die veld kan lees nie, en dit skakel nie 'n eenmalige kode om in iets herbuikbaars nie. Die ingepakte waarde verdien dieselfde hantering as 'n wagwoord: uit gedeelde profiele, uit opdragreëls en uit diagnostiese logs.

Daardie enkodering is ook die algemeenste bron van verwarring, want daar is nou drie vorms wat soortgelyk lyk en nie uitruilbaar is nie. 'n Gewone aanmeldingslêer hou 'n wagwoord. 'n Letterlike aaneenskakeling van wagwoord en kode hou 'n ander string. 'n Bestuurskliënt se ingepakte antwoord hou 'n derde. Bevestig watter een jou verifikasiepad verwag voordat jy 'n veld verander net omdat 'n fout verdwyn het.

Staties teenoor dinamies: verskillende tydsberekening

'n Statiese uitdaging is bekend voordat die eerste geloofsbrief ingedien word, so die kliënt kan dit vooraf vra. 'n Dinamiese uitdaging kom later, gestuur deur die verifikasiestroom nadat 'n uitruiling reeds begin het, en dit vereis 'n kliënt wat 'n versoek midde in die gesprek kan hanteer.

Ondersteuning vir die een gee jou nie die ander nie. 'n Profielopdrag wat 'n statiese opdragteks instel, implementeer nie 'n uitdaging wat deur die bediener begin word nie, en 'n voorkant wat dinamiese versoeke hanteer, wys dalk steeds nie 'n statiese een nie. Om te lees watter kant die versoek begin het, is die vinnigste manier om hulle te onderskei.

Onaanwesige werking is waar dit 'n ontwerpkwessie eerder as 'n koppelvlakkwessie word. 'n Gestoor kode is nie 'n duursame selflaaityd-geloofsbrief nie, en 'n herverbinding ure later sal vars invoer nodig hê, tensy die ontplooiing 'n tokenreëling ondersteun wat die operateur doelbewus geaktiveer het.

Toets sukses en mislukking, nie net die dialoog nie

Voer albei helftes van die toets uit. Korrekte geloofsbriewe met 'n geldige antwoord behoort te slaag; korrekte geloofsbriewe met 'n doelbewus verkeerde antwoord behoort geweier te word. As albei slaag, versamel die kliënt invoer wat niks verifieer nie, en die dialoog is vir 'n kontrole aangesien. Daardie enkele toets vang meer ontplooiings as enige hoeveelheid profielhersiening.

Herhaal dan die verbinding ná 'n herverbinding, met 'n rekening wat nie ingeskryf is nie, en deur watter kliënt jou gebruikers ook al werklik gebruik. Die verskyning van die opdragteks is 'n kliëntgedrag; die weiering van 'n verkeerde kode is die bediener wat iets afdwing.