Kāpēc derīgs vienreizējais kods VPN pieteikšanās laikā tomēr neizdodas

Jūs atverat VPN klientu, ievadāt paroli, un seši cipari no autentifikatora atgriežas kā nederīgi — divreiz, tad trešo reizi. Kontā kopš vakardienas nekas nav mainījies, tāpēc pirmais instinkts ir dzēst autentifikatora ierakstu un to vēlreiz noskenēt — parasti tas ir nepareizais labojums. Vienreizējais kods nav otra parole: vārtejai tas jāprasa noteiktā solī, no noteikta reģistrēta ieraksta, noteiktā logā, un lielākā daļa noraidījumu notiek pirms ciparu salīdzināšanas. Noskaidrojiet, kurā solī esat, pirms aiztiekat reģistrāciju.

Pieprasījumu secība parāda, kurā plūsmā jūs esat

Trīs formas aptver gandrīz katru VPN pieteikšanos, kurā iesaistīts kods. Divu soļu formā klients nosūta paroli, serveris izdod izaicinājumu, un klients jautā vēlreiz. Kombinētajā formā vārteja vēlas paroli un kodu vienā iesniegumā — dažreiz savienotus, dažreiz pēc atdalītāja, ko dokumentē tikai operators. Pārlūka formā klientam nav neviena lauka: kods tiek ievadīts tīmekļa lapā, vai push apstiprinājums to aizstāj, un galddatora klients gaida rezultātu.

Nepareizā forma izskatās kā slikts kods. Ielīmējiet svaigu kodu laukā, kas paredzēts tikai parolei, un serveris to nolasīs kā paroles daļu. Klienta pusē OpenVPN 2.4 un jaunākas versijas padara atšķirību redzamu: serveris, kas atbild AUTH_FAILED,CRV1:, gaida izaicinājuma atbildi, tāpēc profilam nepieciešams static-challenge vai paroles fails SCRV1: formā. Vecāks profils, kam ir tikai auth-user-pass, apstiprina paroli un pēc tam apstājas, kas žurnālā izskatās kā OTP kļūda, lai gan neviens kods netika nosūtīts.

WireGuard ir pelnījis tikt nosaukts kā izņēmums: tas autentificē atslēgu pārus, nevis cilvēkus, tāpēc koda lauka nav. Ja pakalpojumu sniedzējs tādu reklamē, to pieņem kaut kas ārpus tuneļa.

Ko serveris dara ar sešiem cipariem

Uz laiku balstīti kodi seko RFC 6238, kas ietver vecāko uz skaitītāju balstīto konstrukciju no RFC 4226: HMAC virs kustīga faktora, pēc noklusējuma saīsināts līdz sešiem cipariem. TOTP gadījumā kustīgais faktors ir pašreizējais Unix laiks, dalīts ar soli, 30 sekundes, ja vien operators to nav mainījis. Pārbaudītājs nekad nesalīdzina jūsu ciparus ar saglabātu vērtību; tas pārrēķina gaidīto kodu no kopīgās sēklas un parasti pieņem arī blakus soļus, tāpēc lēns ceļš uz priekšu un atpakaļ neizraisa pieteikšanās neizdošanos.

Divi secinājumi paliek nepamanīti. Tālruņa laika joslai nav nozīmes, jo sēkla nekad neredz vietējo pulksteni — svarīga ir tikai novirze no īstā UTC, un ierīce, kas steidzas divas minūtes uz priekšu, neizdodas ar katru kodu, vienlaikus rādot tīru atskaiti. Un kods pēc konstrukcijas ir vienreizējs: pārbaudītājs atceras pēdējo skaitītāja vērtību, ko tas pieņēma šai sēklai, tāpēc tie paši cipari, kas iesniegti vēlreiz, tiek noraidīti pat tajā pašā logā. Klients, kas pēc noildzes mēģina vēlreiz, var izdedzināt tikko nosūtīto kodu.

Uz skaitītāju balstīti marķieri katru reizi nospiežot pārbīda skaitītāju, tāpēc tie izkrīt no sinhronizācijas pēc tam, kad kodi ir ģenerēti, bet nekad nav nosūtīti; parastais labojums ir resinhronizācijas logs, kas pieņem dažas vērtības uz priekšu. Ja operators reģistrēja HOTP, bet jūsu lietotne rāda TOTP, katra vērtība ir nepareiza tā, ka tas izskatās pēc pulksteņa problēmas. QR koda aizmugurē esošais nodrošinājuma URI nosauc tipu, ciparus, periodu un jaucējvērtību.

Neizdošanās, kas izskatās kā nepareizs kods

Visbiežākais vaininieks ir reģistrētais ieraksts. Autentifikatora lietotnes marķē ierakstus pēc izdevēja un konta, tāpēc ikviens, kam ir divas identitātes vienā VPN, var nonākt pie diviem ierakstiem, kuru marķējumi atšķiras par vienu rakstzīmi. Kods ir derīgs tikai tai sēklai, kas to ģenerēja, un nekam citam. Salīdziniet marķējumu telefonā ar lietotājvārdu, ko serveris reģistrē, nevis ar to, ko atceraties ievadījis.

Otrais ir neatbilstoša parametru kopa. Sēkla, kas reģistrēta ar astoņiem cipariem, 60 sekunžu periodu vai SHA-256, dod kodus, kurus pārbaudītājs, kas gaida sešus ciparus, 30 sekundes un SHA-1, noraida, un klientā to nevar atšķirt no nepareiza koda. Tas parādās pēc migrācijām, kur ieraksts tika pievienots no jauna no QR koda fotogrāfijas, vai kur marķiera ieraksts tika pārbūvēts ar noklusējuma vērtībām.

Trešais nav par kodu. Vārtejas parasti atgriež vienu vispārīgu autentifikācijas kļūdu par nepareizu paroli, beigušos kodu un atspējotu kontu, apzināti, lai neviens nevarētu noskaidrot, kurš faktors neizdevās. Lasiet vārtejas vai RADIUS žurnālu, nevis klienta ziņojumu: neizdots izaicinājums, piekļuves liegums bez OTP atribūta un politikas liegums ekrānā izskatās vienādi un ved pie atšķirīgiem nākamajiem soļiem.

Īsa secība, kas to sašaurina

Sāciet ar lētāko pārbaudi un apstājieties pie pirmā soļa, kas neiztur.

1. Pagaidiet svaigu kodu, iesniedziet to vienreiz un atzīmējiet, vai izaicinājums parādās pirms paroles pieņemšanas vai pēc tam.
2. Saskaņojiet autentifikatora marķējumu ar lietotājvārdu, ko serveris glabā.
3. Apstipriniet, ka profils vispār spēj atbildēt uz izaicinājumu, kā iepriekš CRV1 gadījumā.
4. Salīdziniet ierīces pulksteni ar zināmu laika avotu; lielāka par dažām desmitiem sekunžu novirze pati sabojā TOTP.
5. Pajautājiet operatoram, vai marķieris ir TOTP vai HOTP, un kādi cipari, periods un jaucējvērtība tika reģistrēti.

Divi noteikumi neļauj tam pasliktināties. Nemēģiniet daudzas reizes: daudzas vārtejas skaita neizdošanās uz kontu un vai nu to bloķē, vai sāk aizkavēt atbildes, tāpēc uzplūdums pārvērš nelielu konfigurācijas kļūdu atbalsta pieteikumā. Un nepārreģistrējiet marķieri diagnostikas nolūkā, jo tas padara veco sēklu nederīgu; ja īstā vaina bija izaicinājums, ko klients nekad nenosūtīja, tagad jums ir divas izmaiņas jāizskaidro, nevis viena.

Turiet sēklu un atjaunošanas kodus ārpus loka

Seši cipari un aiz tiem esošais noslēpums nav savstarpēji aizvietojami. Nodrošinājuma QR kods vai Base32 sēkla ģenerē katru nākamo konta kodu, tāpēc tā pieder tai pašai kategorijai kā parole: ne ekrānuzņēmumā, ne pieteikuma komentārā, ne sarunā ar cilvēku, kurš pirmais ar jums sazinājās. Atjaunošanas kodi ir atsevišķs mehānisms — vienreizēji, bieži pilnībā izlaiž koda pieprasījumu, un viena iztērēšana konta pārbaudei atņem rezerves ceļu, kas varētu būt vajadzīgs vēlāk.

Kods arī nepadara pieteikšanās lapu uzticamu: OTP pieprasījums līdzīgā domēnā savāc derīgu kodu un atkārto to loga ietvaros, un sertifikāts joprojām ir tas, kas pasaka, kur jūs rakstāt.

Ja secība nonāk pie profila, kas nevar atbildēt uz izaicinājumu, izlabojiet profilu un pārbaudiet vēlreiz ar vienu svaigu kodu. Ja tā nonāk pie neatbilstošiem reģistrācijas parametriem, palūdziet operatoram nolasīt marķiera ierakstu, pirms kāds kaut ko skenē. Ja tā nonāk pie bloķēšanas, nogaidiet to, tā vietā lai mainītu klientus — šķērslis ir konta stāvoklis, nevis lietotne.