Kodėl galiojantis vienkartinis kodas vis tiek nepavyksta prisijungiant prie VPN

Atidarote VPN klientą, įvedate slaptažodį, ir šeši autentifikatoriaus skaitmenys grįžta kaip negaliojantys — du kartus, paskui trečią. Paskyroje nuo vakar niekas nepasikeitė, todėl pirmas impulsas yra ištrinti autentifikatoriaus įrašą ir jį nuskenuoti iš naujo — paprastai tai neteisingas taisymas. Vienkartinis kodas nėra antras slaptažodis: tarpinė turi jo paprašyti tam tikrame žingsnyje, iš tam tikro užregistruoto įrašo, tam tikrame lange, ir dauguma atmetimų įvyksta prieš palyginant skaitmenis. Nustatykite, kuriame žingsnyje esate, prieš liesdami registraciją.

Užklausų eiliškumas parodo, kuriame sraute esate

Trys formos apima beveik kiekvieną VPN prisijungimą su kodu. Dviejų žingsnių formoje klientas siunčia slaptažodį, serveris išduoda iššūkį, o klientas vėl klausia. Sudėtinėje formoje tarpinė nori slaptažodžio ir kodo viename pateikime — kartais sujungtų, kartais po skyriklio, kurį dokumentuoja tik operatorius. Naršyklės formoje klientas neturi jokio lauko: kodas įvedamas į tinklalapį, arba stūmimo patvirtinimas jį pakeičia, o darbalaukio klientas laukia rezultato.

Neteisinga forma atrodo kaip blogas kodas. Įklijuokite naują kodą į lauką, skirtą tik slaptažodžiui, ir serveris perskaitys jį kaip slaptažodžio dalį. Kliento pusėje OpenVPN 2.4 ir naujesnės versijos padaro skirtumą matomą: serveris, atsakantis AUTH_FAILED,CRV1:, tikisi iššūkio atsakymo, todėl profiliui reikia static-challenge arba slaptažodžio failo SCRV1: forma. Senesnis profilis, turintis tik auth-user-pass, patvirtina slaptažodį ir tada sustoja, o žurnale tai atrodo kaip OTP gedimas, nors joks kodas nebuvo išsiųstas.

WireGuard verta paminėti kaip išimtį: jis autentifikuoja raktų poras, o ne žmones, todėl kodo lauko nėra. Jei tiekėjas tokį reklamuoja, jį priima kažkas už tunelio ribų.

Ką serveris daro su šešiais skaitmenimis

Laiku pagrįsti kodai vadovaujasi RFC 6238, kuris apgaubia senesnę skaitikliu pagrįstą konstrukciją iš RFC 4226: HMAC virš judančio veiksnio, pagal nutylėjimą sutrumpintas iki šešių skaitmenų. TOTP atveju judantis veiksnys yra dabartinis Unix laikas, padalytas iš žingsnio, 30 sekundžių, jei operatorius jo nepakeitė. Tikrintojas niekada nelygina jūsų skaitmenų su išsaugota reikšme; jis perskaičiuoja laukiamą kodą iš bendros sėklos ir paprastai priima ir gretimus žingsnius, todėl lėta kelionė pirmyn ir atgal nesutrikdo prisijungimo.

Dvi pasekmės praleidžiamos. Telefono laiko juosta neturi reikšmės, nes sėkla niekada nemato vietinio laikrodžio — svarbus tik nuokrypis nuo tikrojo UTC, o dviem minutėmis pabėgęs įrenginys nepavyksta prie kiekvieno kodo, rodydamas tvarkingą atgalinį skaičiavimą. Ir kodas pagal konstrukciją yra vienkartinis: tikrintojas atsimena paskutinę tos sėklos priimtą skaitiklio reikšmę, todėl tie patys skaitmenys, pateikti dar kartą, atmetami net tame pačiame lange. Klientas, kuris po laiko limito bando dar kartą, gali sudeginti ką tik išsiųstą kodą.

Skaitikliu pagrįsti žetonai kiekvieną kartą paspaudus pastumia skaitiklį, todėl jie iškrenta iš sinchronizacijos, kai kodai sugeneruojami, bet niekada neišsiunčiami; įprastas taisymas yra resinchronizacijos langas, priimantis kelias reikšmes į priekį. Jei operatorius užregistravo HOTP, o jūsų programa rodo TOTP, kiekviena reikšmė yra neteisinga taip, kad atrodo kaip laikrodžio problema. QR kodo užnugaryje esantis paruošimo URI nurodo tipą, skaitmenis, periodą ir maišą.

Gedimai, kurie atrodo kaip neteisingas kodas

Dažniausia kaltininkė yra užregistruotas įrašas. Autentifikatoriaus programos žymi įrašus pagal išdavėją ir paskyrą, todėl kas turi dvi tapatybes tame pačiame VPN, gali turėti du įrašus, kurių etiketės skiriasi vienu simboliu. Kodas galioja tik jį sugeneravusiai sėklai ir niekam kitam. Palyginkite telefono etiketę su vartotojo vardu, kurį įrašo serveris, o ne su tuo, kurį prisimenate įvedę.

Antra — nesuderintas parametrų rinkinys. Sėkla, užregistruota su aštuoniais skaitmenimis, 60 sekundžių periodu arba SHA-256, duoda kodus, kuriuos tikrintojas, laukiantis šešių skaitmenų, 30 sekundžių ir SHA-1, atmeta, o kliente to negalima atskirti nuo neteisingo kodo. Tai pasireiškia po migracijų, kai įrašas buvo pridėtas iš naujo iš QR kodo nuotraukos arba kai žetono įrašas buvo atkurtas su numatytosiomis reikšmėmis.

Trečia — tai ne apie kodą. Tarpinės paprastai grąžina vieną bendrą autentifikacijos gedimą dėl neteisingo slaptažodžio, pasibaigusio kodo ir išjungtos paskyros, sąmoningai, kad niekas negalėtų išsiaiškinti, kuris veiksnys nepavyko. Skaitykite tarpinės arba RADIUS žurnalą, o ne kliento pranešimą: neišduotas iššūkis, prieigos atmetimas be OTP atributo ir politikos atmetimas ekrane atrodo vienodai ir veda prie skirtingų tolesnių veiksmų.

Trumpa seka, kuri susiaurina

Pradėkite nuo pigiausios patikros ir sustokite ties pirmuoju žingsniu, kuris nepasitvirtina.

1. Palaukite naujo kodo, pateikite jį vieną kartą ir atkreipkite dėmesį, ar iššūkis pasirodo prieš priimant slaptažodį, ar po to.
2. Suderinkite autentifikatoriaus etiketę su vartotojo vardu, kurį saugo serveris.
3. Patvirtinkite, kad profilis apskritai gali atsakyti į iššūkį, kaip aukščiau CRV1 atveju.
4. Palyginkite įrenginio laikrodį su žinomu laiko šaltiniu; didesnis nei kelių dešimčių sekundžių nuokrypis pats sugadina TOTP.
5. Paklauskite operatoriaus, ar žetonas yra TOTP, ar HOTP, ir kokie skaitmenys, periodas bei maiša buvo užregistruoti.

Dvi taisyklės neleidžia tam pablogėti. Nekartokite daug kartų: daugelis tarpinių skaičiuoja gedimus pagal paskyrą ir arba ją užrakina, arba pradeda vėlinti atsakymus, todėl pliūpsnis mažą konfigūracijos klaidą paverčia pagalbos bilietu. Ir neperregistruokite žetono diagnostikos tikslais, nes tai panaikina seną sėklą; jei tikroji bėda buvo iššūkis, kurio klientas niekada neišsiuntė, dabar turite du pakeitimus paaiškinti, o ne vieną.

Laikykite sėklą ir atkūrimo kodus už rato ribų

Šeši skaitmenys ir jų slepinys nėra pakeičiami. Paruošimo QR kodas arba Base32 sėkla sugeneruoja kiekvieną būsimą paskyros kodą, todėl ji priklauso tai pačiai kategorijai kaip slaptažodis: ne ekrano nuotraukoje, ne bilieto komentare, ne pokalbyje su žmogumi, kuris pirmasis su jumis susisiekė. Atkūrimo kodai yra atskiras mechanizmas — vienkartiniai, dažnai visiškai praleidžia kodo užklausą, o išleidus vieną paskyrai išbandyti prarandamas atsarginis kelias, kurio gali prireikti vėliau.

Kodas taip pat nepadaro prisijungimo puslapio patikimu: OTP užklausa panašiame domene surenka galiojantį kodą ir pakartoja jį tame pačiame lange, o sertifikatas vis dar yra tai, kas pasako, kur jūs rašote.

Jei seka baigiasi profilyje, kuris negali atsakyti į iššūkį, sutaisykite profilį ir patikrinkite iš naujo vienu nauju kodu. Jei ji baigiasi nesuderintais registracijos parametrais, paprašykite operatoriaus perskaityti žetono įrašą, kol kas nors ką nors nuskaito. Jei ji baigiasi užrakinimu, palaukite, kol jis praeis, o ne keiskite klientus — kliūtis yra paskyros būsena, o ne programa.