Zergatik hutsegiten duen oraindik baliozko kode bakarrekoak VPN saio-hasieran

VPN bezeroa irekitzen duzu, pasahitza idazten duzu, eta autentifikatzaileko sei zifrak baliogabe gisa itzultzen dira — birritan, gero hirugarren aldiz. Kontuan ez da ezer aldatu atzotik, beraz senak autentifikatzaileko sarrera ezabatu eta berriro eskaneatzea dio — normalean konponketa okerra. Kode bakarreko bat ez da bigarren pasahitz bat: ateak urrats jakin batean eskatu behar du, erregistratutako sarrera jakin batetik, leiho jakin baten barruan, eta baztertze gehienak zifrak alderatu aurretik gertatzen dira. Zehaztu zein urratsetan zauden erregistroa ukitu aurretik.

Eskaeren ordenak esaten dizu zein fluxutan zauden

Hiru formak estaltzen dute kode bat dakarren VPN saio-hasiera ia guztia. Bi urratseko forman bezeroak pasahitza bidaltzen du, zerbitzariak erronka bat jaulkitzen du, eta bezeroak berriro galdetzen du. Forma konbinatuan ateak pasahitza eta kodea bidalketa bakarrean nahi ditu — batzuetan elkarri lotuta, batzuetan operadoreak soilik dokumentatzen duen bereizle baten ondoren. Nabigatzailearen forman bezeroak ez du eremurik: kodea web orri batera doa, edo push onespen batek ordezkatzen du, eta mahaigaineko bezeroak emaitzaren zain egoten da.

Forma okerra kode txar bat bezala ikusten da. Itsatsi kode berri bat pasahitzerako soilik den eremu batean, eta zerbitzariak pasahitzaren parte gisa irakurriko du. Bezeroaren aldean, OpenVPN 2.4 eta berriagoek aldea ikusgai egiten dute: AUTH_FAILED,CRV1:-rekin erantzuten duen zerbitzari batek erronkari erantzuna espero du, beraz profilean static-challenge edo SCRV1: formako pasahitz fitxategia behar da. auth-user-pass soilik daraman profil zahar batek pasahitza balioztatu eta gero gelditzen da, eta hori erregistroan OTP hutsegite bat bezala agertzen da, nahiz eta koderik bidali ez.

WireGuard salbuespen gisa aipatzea merezi du: gako bikoteak autentifikatzen ditu, ez pertsonak, beraz ez dago koderako eremurik. Hornitzaile batek bat iragartzen badu, tunelaren kanpoko zerbait da onartzen duena.

Zer egiten du zerbitzariak sei zifrekin

Denboran oinarritutako kodeek RFC 6238 jarraitzen dute, eta horrek RFC 4226-ko kontagailuan oinarritutako eraikuntza zaharragoa biltzen du: faktore mugikor baten gaineko HMAC bat, lehenespenez sei zifretara moztuta. TOTPn faktore mugikorra uneko Unix denbora urratsez zatituta da, 30 segundo, operadoreak aldatu ez badu. Egiaztatzaileak ez ditu inoiz zure zifrak gordetako balio batekin alderatzen; kode esperotakoa hazitik berrikusten du eta normalean ondoko urratsak ere onartzen ditu, beraz joan-etorri geldoak ez du saio-hasiera hutsegitetsiko.

Bi ondorio ez dira kontuan hartzen. Telefonoaren ordu-eremua ez da garrantzitsua, haziak ez baitu inoiz erloju lokalik ikusten — UTC errealarekiko desbideratzea soilik da garrantzitsua, eta bi minutu aurreratuta dagoen gailu batek kode guztietan huts egiten du atzera-kontaketa garbia erakusten duen bitartean. Eta kodea erabilera bakarrekoa da diseinuz: egiaztatzaileak hazi horretarako onartu zuen azken kontagailu-balioa gogoratzen du, beraz birritan bidalitako zifra berak baztertzen dira leiho berean ere. Denbora-muga baten ondoren berriro saiatzen den bezero batek berriki bidalitako kodea erre dezake.

Kontagailuan oinarritutako tokenek kontagailua mugitzen dute sakatze bakoitzean, beraz sinkronizaziotik ateratzen dira kodeak sortu baina inoiz bidali gabe geratu ondoren; ohiko konponketa aurrera begira balio batzuk onartzen dituen birsinkronizazio-leiho bat da. Operadoreak HOTP erregistratu badu eta zure aplikazioak TOTP erakusten badu, balio guztiak okerrak dira erloju arazo baten itxura egiten duen moduan. QR kodearen atzean dagoen hornikuntza-URIak mota, zifrak, periodoa eta hash-a izendatzen ditu.

Kode okerraren itxura duten hutsegiteak

Erregistratutako sarrera da errudun ohikoena. Autentifikatzaile aplikazioek sarrerak jaulkitzailearen eta kontuaren arabera etiketatzen dituzte, beraz VPN berean bi identitate dituen edonor bi sarreratan gera daiteke, haien etiketak karaktere batean desberdinak direla. Kode bat sortu zuen haziarentzat da baliozkoa eta ez beste ezerentzat. Konparatu telefonoan dagoen etiketa zerbitzariak gordetzen duen erabiltzaile-izenarekin, ez idatzi zenuela gogoratzen duzunarekin.

Bigarrena bat ez datorren parametro-multzo bat da. Zortzi zifrarekin, 60 segundoko periodoa edo SHA-256 erabiliz erregistratutako hazi batek sei zifra, 30 segundo eta SHA-1 espero dituen egiaztatzaileak baztertzen dituen kodeak ematen ditu, eta bezeroan hori ezin da kode oker batetik bereizi. Migrazioen ondoren agertzen da, sarrera QR kodearen argazki batetik berriro gehitu zenean, edo token erregistroa lehenespen-balioekin berreraiki zenean.

Hirugarrena ez da kodearen kontua. Ateek normalean autentifikazio-hutsegite orokor bakarra itzultzen dute pasahitz okerra, iraungitako kodea eta desgaitutako kontua batera, nahita, inork zein faktorek huts egin duen egiazta ez dezan. Irakurri ateen edo RADIUS-en erregistroa bezeroaren mezuaren ordez: inoiz jaulki gabeko erronka bat, OTP atributurik gabeko sarbide-ukatzea eta politika-ukatzea berdin ikusten dira pantailan eta hurrengo urrats desberdinetara eramaten dute.

Hau mugatzen duen segida labur bat

Hasi egiaztapen merkeenetik eta gelditu betetzen ez den lehen urratsean.

1. Itxaron kode berri bat, bidali behin, eta ohartu erronka pasahitza onartu aurretik edo ondoren agertzen den.
2. Pareka ezazu autentifikatzaileko etiketa zerbitzariak gordetzen duen erabiltzaile-izenarekin.
3. Berretsi profilak erronkari erantzuteko gai dela, goiko CRV1 kasuan bezala.
4. Konparatu gailuaren erlojua ezagututako denbora-iturri batekin; hogeita hamar segundo batzuk baino desbideratze handiagoak TOTP bera hausten du.
5. Galdetu operadoreari tokena TOTP ala HOTP den, eta zein zifra, periodo eta hash erregistratu ziren.

Bi arauk eragozten dute hau okerragotzea. Ez saiatu askotan: ate askok kontu bakoitzeko hutsegiteak zenbatzen dituzte eta edo blokeatu egiten dute edo erantzunak atzeratzen hasi, beraz segidak konfigurazio-errore txiki bat laguntza-txartel bihur dezake. Eta ez erregistratu berriro tokena diagnostiko gisa, hazi zaharra baliogabetzen baitu; benetako akatsa bezeroak inoiz bidali ez zuen erronka bat bazen, orain aldaketa bat beharrean bi dituzu azaltzeko.

Eduki hazia eta berreskuratze-kodeak zirkuituetatik kanpo

Sei zifrak eta haien atzeko sekretua ez dira trukagarriak. Hornikuntza QR kode batek edo Base32 hazi batek kontuaren etorkizuneko kode guztiak sortzen ditu, beraz pasahitzaren kategoria berekoa da: ez pantaila-argazki batean, ez txartelaren iruzkin batean, ez lehenengo zurekin harremanetan jarri zen norbaitekin izandako txatean. Berreskuratze-kodeak mekanismo bereizi bat dira — erabilera bakarrekoak, sarritan kode-eskaera erabat saihesten dute, eta bat kontua probatzeko gastatzeak geroago behar dezakezun ordezko bide bat ezabatzen du.

Kode batek ez du saio-hasierako orria fidagarri egiten: antzeko domeinu bateko OTP eskaera batek baliozko kode bat biltzen du eta leihoaren barruan berriz erreproduzitzen du, eta ziurtagiriak jarraitzen du esaten non idazten ari zaren.

Segidak erronkari erantzun ezin dion profil batean amaitzen badu, konpondu profila eta probatu berriro kode berri batekin. Erregistro-parametro desberdinetan amaitzen badu, eskatu operadoreari token erregistroa irakurtzeko inork ezer eskaneatu aurretik. Blokeo batean amaitzen badu, itxaron pasa dadin bezeroa aldatu beharrean — kontuaren egoera da oztopoa, ez aplikazioa.