Miks kehtiv ühekordne kood VPN-i sisselogimisel siiski ebaõnnestub

Avate VPN-kliendi, sisestate parooli ja autentija kuus numbrit tulevad tagasi kehtetutena — kaks korda, siis kolmandat korda. Kontol pole eilsest midagi muutunud, nii et esimene mõte on autentija kanne kustutada ja uuesti skaneerida — tavaliselt vale parandus. Ühekordne kood ei ole teine parool: lüüs peab seda küsima kindlas sammus, kindlast registreeritud kandest, kindla ajavahemiku jooksul, ja enamik tagasilükkamisi toimub enne, kui numbreid võrreldakse. Tehke kindlaks, millises sammus olete, enne kui registreerimist puutute.

Päringute järjekord näitab, millises voos olete

Kolm kuju katavad peaaegu iga VPN-i sisselogimise, mis sisaldab koodi. Kahesammulises kujus saadab klient parooli, server väljastab väljakutse ja klient küsib uuesti. Kombineeritud kujus tahab lüüs parooli ja koodi ühes saatmises — mõnikord kokku liidetuna, mõnikord eraldaja järel, mida dokumenteerib ainult operaator. Brauseri kujus pole kliendil üldse välja: kood läheb veebilehele või asendab selle push-kinnitus, ja töölauaklient ootab tulemust.

Vale kuju tundub halva koodina. Kleepige värske kood ainult parooli jaoks mõeldud väljale ja server loeb selle parooli osaks. Kliendi poolel teevad OpenVPN 2.4 ja uuemad vahe nähtavaks: server, mis vastab AUTH_FAILED,CRV1:, ootab väljakutse vastust, seega vajab profiil static-challenge seadet või paroolifaili kujul SCRV1:. Vanem profiil, millel on ainult auth-user-pass, valideerib parooli ja jääb siis seisma, mis logis näeb välja nagu OTP-tõrge, kuigi ühtegi koodi ei saadetud.

WireGuard tasub nimetada erandiks: see autendib võtmepaare, mitte inimesi, seega pole koodi jaoks välja. Kui teenusepakkuja seda reklaamib, võtab selle vastu miski väljaspool tunnelit.

Mida server kuue numbriga teeb

Ajal põhinevad koodid järgivad RFC 6238, mis mähib RFC 4226 vanema loenduripõhise konstruktsiooni: HMAC liikuva teguri kohal, vaikimisi kuue numbrini kärbitud. TOTP puhul on liikuv tegur praegune Unix-aeg jagatud sammuga, 30 sekundit, kui operaator pole seda muutnud. Kontrollija ei võrdle kunagi teie numbreid salvestatud väärtusega; see arvutab oodatava koodi jagatud seemnest uuesti ja aktsepteerib tavaliselt ka naabersamme, nii et aeglane edasi-tagasi käik ei kukuta sisselogimist läbi.

Kaks tagajärge jäävad märkamata. Telefoni ajavöönd ei loe, sest seeme ei näe kunagi kohalikku kella — tähtis on ainult kõrvalekalle tegelikust UTC-st, ja kaks minutit ette tõttav seade kukub igal koodil läbi, näidates samal ajal korralikku loendust. Ja kood on disaini järgi ühekordne: kontrollija mäletab viimast loenduri väärtust, mille ta selle seemne jaoks vastu võttis, nii et samad numbrid, mis uuesti esitatakse, lükatakse tagasi isegi sama ajavahemiku sees. Klient, mis pärast ajalõppu uuesti proovib, võib just saadetud koodi ära põletada.

Loenduripõhised võtmed liigutavad loendurit iga vajutusega, nii et need kaotavad sünkrooni pärast seda, kui koodid on genereeritud, kuid mitte kunagi saadetud; tavaline parandus on resünkroonimisaken, mis aktsepteerib mõned väärtused ette. Kui operaator registreeris HOTP, aga teie rakendus näitab TOTP-d, on iga väärtus valesid nii, et see näeb välja nagu kellaprobleem. QR-koodi taga olev provisjoneerimis-URI nimetab tüübi, numbrid, perioodi ja räsi.

Tõrked, mis näevad välja nagu vale kood

Registreeritud kanne on kõige tavalisem süüdlane. Autentijad märgistavad kandeid väljaandja ja konto järgi, nii et kellel on samas VPN-is kaks identiteeti, võib lõpuks olla kaks kannet, mille sildid erinevad ühe tähemärgi võrra. Kood kehtib seemne jaoks, mis selle genereeris, ja mitte millegi muu jaoks. Võrrelge telefonil olevat silti kasutajanimega, mille server salvestab, mitte sellega, mida mäletate, et sisestasite.

Teine on sobimatu parameetrite komplekt. Kaheksa numbriga, 60 sekundi pikkuse perioodi või SHA-256-ga registreeritud seeme annab koode, mille kontrollija, kes ootab kuut numbrit, 30 sekundit ja SHA-1, tagasi lükkab, ja kliendil pole seda valest koodist võimalik eristada. See ilmneb pärast migratsioone, kus kanne lisati uuesti QR-koodi foto põhjal või kus võtme kirje ehitati vaikeväärtustega uuesti üles.

Kolmas ei puuduta koodi. Lüüsid tagastavad tavaliselt vale parooli, aegunud koodi ja keelatud konto jaoks ühe üldise autentimistõrke, meelega, et keegi ei saaks uurida, milline tegur ebaõnnestus. Lugege kliendi bänneri asemel lüüsi või RADIUS-e logi: väljakutse, mida kunagi ei väljastatud, juurdepääsu keeld ilma OTP-atribuudita ja poliitikakeeld näevad ekraanil ühesugused välja ning viivad erinevate järgmiste sammudeni.

Lühike järjestus, mis seda kitsendab

Alustage kõige odavamast kontrollist ja peatuge esimesel sammul, mis ei pea.

1. Oodake värsket koodi, esitage see üks kord ja pange tähele, kas väljakutse ilmub enne või pärast parooli vastuvõtmist.
2. Sobitage autentija silt serveri salvestatud kasutajanimega.
3. Kinnitage, et profiil üldse suudab väljakutsele vastata, nagu ülal CRV1 juhtumis.
4. Võrrelge seadme kella tuntud ajaallikaga; üle mõnekümne sekundi suurune kõrvalekalle rikub TOTP-i iseenesest.
5. Küsige operaatorilt, kas võti on TOTP või HOTP, ja millised numbrid, periood ning räsi registreeriti.

Kaks reeglit hoiavad seda asja hullemaks muutumast. Ärge proovige palju kordi: paljud lüüsid loevad tõrkeid konto kohta ja kas lukustavad selle või hakkavad vastuseid edasi lükkama, nii et purse muudab väikese valeseade toe-piletiks. Ja ärge registreerige võtit diagnostikaks uuesti, sest see muudab vana seemne kehtetuks; kui tegelik viga oli väljakutse, mida klient kunagi ei saatnud, on teil nüüd ühe asemel kaks muudatust, mida seletada.

Hoidke seeme ja taastekoodid ringist väljas

Kuus numbrit ja nende taga olev saladus ei ole vahetatavad. Provisjoneerimis-QR-kood või Base32 seeme genereerib konto iga tulevase koodi, seega kuulub see parooliga samasse kategooriasse: mitte ekraanipildile, mitte pileti kommentaari, mitte vestlusesse kellegagi, kes võttis teiega esimesena ühendust. Taastekoodid on eraldi mehhanism — ühekordsed, sageli jätavad koodiküsimuse täiesti vahele, ja kui kulutate ühe konto testimiseks, kaotate varuvõimaluse, mida võite hiljem vajada.

Kood ei tee ka sisselogimislehte usaldusväärseks: OTP-küsimus sarnasel domeenil kogub kehtiva koodi ja kordab selle ajavahemiku sees, ning sertifikaat on endiselt see, mis ütleb, kuhu te sisestate.

Kui järjestus jõuab profiilini, mis ei suuda väljakutsele vastata, parandage profiil ja proovige uuesti ühe värske koodiga. Kui see jõuab sobimatute registreerimisparameetriteni, laske operaatoril võtmekirje läbi lugeda, enne kui keegi midagi skaneerib. Kui see jõuab lukustuseni, oodake see ära, selle asemel et kliente vahetada — takistus on konto olek, mitte rakendus.