Zašto ispravan jednokratni kod ipak ne prolazi pri prijavi na VPN

Otvorite VPN klijent, upišete lozinku, a šest cifara iz autentikatora se vraćaju kao neispravne — dvaput, pa treći put. Ništa se na računu nije promijenilo od jučer, pa je prvi poriv obrisati unos u autentikatoru i ponovo ga skenirati — obično je to pogrešna popravka. Jednokratni kod nije druga lozinka: pristupnik ga mora tražiti u određenom koraku, iz određenog upisanog unosa, unutar određenog prozora, a većina odbijanja dogodi se prije nego što se cifre uporede. Utvrdite u kojem ste koraku prije nego što dirate upis.

Redoslijed upita pokazuje u kojem toku ste

Tri oblika pokrivaju gotovo svaku prijavu na VPN koja uključuje kod. U dvokoračnom obliku klijent šalje lozinku, server izdaje izazov, a klijent ponovo pita. U kombinovanom obliku pristupnik traži lozinku i kod u jednom slanju — ponekad spojene, ponekad nakon razdjelnika koji dokumentuje samo operater. U obliku s preglednikom klijent uopće nema polje: kod ide na web stranicu ili ga odobrenje pritiskom zamjenjuje, a stolni klijent čeka rezultat.

Pogrešan oblik izgleda kao loš kod. Zalijepite svjež kod u polje samo za lozinku i server ga pročita kao dio lozinke. Na strani klijenta OpenVPN 2.4 i noviji čine razliku vidljivom: server koji odgovara s AUTH_FAILED,CRV1: očekuje odgovor na izazov, pa profilu treba static-challenge ili datoteka s lozinkom u obliku SCRV1:. Stariji profil samo s auth-user-pass provjeri lozinku i zatim stane, što u zapisu izgleda kao otkaz OTP-a iako kod nije poslan.

WireGuard vrijedi navesti kao izuzetak: on provjerava parove ključeva, a ne ljude, pa nema polja za kod. Ako pružalac takav oglašava, nešto izvan tunela ga prihvata.

Šta server radi sa šest cifara

Kodovi zasnovani na vremenu slijede RFC 6238, koji obavija stariju konstrukciju s brojačem iz RFC 4226: HMAC nad pokretnim faktorom, po pravilu skraćen na šest cifara. Za TOTP je pokretni faktor trenutno Unix vrijeme podijeljeno korakom, 30 sekundi osim ako operater nije promijenio. Verifikator nikada ne poredi vaše cifre sa sačuvanom vrijednošću; preračunava očekivani kod iz zajedničkog sjemena i obično prihvata i susjedne korake, pa sporo putovanje ne ruši prijavu.

Dvije posljedice se propuštaju. Vremenska zona telefona nije važna, jer sjeme nikada ne vidi lokalni sat — važno je samo odstupanje od stvarnog UTC, a aparat koji žuri dvije minute ruši svaki kod dok pokazuje uredno odbrojavanje. I kod je jednokratan po dizajnu: verifikator pamti posljednju vrijednost brojača koju je prihvatio za to sjeme, pa se iste cifre poslane ponovo odbijaju čak i unutar istog prozora. Klijent koji pokuša ponovo nakon isteka može spaliti kod koji je upravo poslao.

Tokeni s brojačem pomjeraju brojač pri svakom pritisku, pa ispadnu iz sinkronizacije nakon što su kodovi generisani ali nikada poslani; uobičajena popravka je prozor za resinhronizaciju koji prihvata nekoliko vrijednosti unaprijed. Ako je operater upisao HOTP a vaša aplikacija prikazuje TOTP, svaka vrijednost je pogrešna na način koji izgleda kao problem sa satom. URI za dodjelu iza QR koda imenuje tip, cifre, period i hash.

Otkazi koji izgledaju kao pogrešan kod

Upisani unos je najčešći krivac. Aplikacije autentikatora označavaju unose po izdavaocu i računu, pa onaj ko ima dva identiteta na istom VPN-u može završiti s dva unosa čije se oznake razlikuju u jednom znaku. Kod vrijedi za sjeme koje ga je generisalo i ni za šta drugo. Uporedite oznaku na telefonu s korisničkim imenom koje server bilježi, a ne s onim što se sjećate da ste upisali.

Drugo je neusklađen skup parametara. Sjeme upisano s osam cifara, periodom od 60 sekundi ili SHA-256 daje kodove koje verifikator koji očekuje šest cifara, 30 sekundi i SHA-1 odbija, a kod klijenta se to ne razlikuje od pogrešnog koda. Pojavljuje se nakon migracija u kojima je unos ponovo dodan sa fotografije QR koda ili je zapis tokena obnovljen s podrazumijevanim vrijednostima.

Treće nije o kodu. Pristupnici obično vraćaju jednu opću grešku provjere za pogrešnu lozinku, istekao kod i onemogućen račun, namjerno, da niko ne može ispitati koji je faktor pao. Čitajte zapis pristupnika ili RADIUS-a umjesto obavještenja klijenta: izazov koji nikada nije izdat, odbijanje pristupa bez OTP atributa i odbijanje po pravilu na ekranu izgledaju isto i vode do različitih sljedećih koraka.

Kratak slijed koji sužava krug

Počnite s najjeftinijom provjerom i zaustavite se na prvom koraku koji ne drži.

1. Sačekajte svjež kod, pošaljite ga jednom i zabilježite da li se izazov pojavljuje prije ili nakon prihvatanja lozinke.
2. Uparite oznaku u autentikatoru s korisničkim imenom koje server čuva.
3. Potvrdite da profil uopće može odgovoriti na izazov, kao u slučaju CRV1 gore.
4. Uporedite sat uređaja s poznatim izvorom vremena; odstupanje veće od nekoliko desetina sekundi samo po sebi kvari TOTP.
5. Pitajte operatera je li token TOTP ili HOTP i koje su cifre, period i hash upisani.

Dva pravila sprečavaju da ovo pogorša stvari. Ne pokušavajte mnogo puta: mnogi pristupnici broje otkaze po računu i ili ga zaključaju ili počnu odgađati odgovore, pa nalet pretvara malu grešku u konfiguraciji u zahtjev podršci. I ne upisujte token ponovo kao dijagnostiku, jer to poništava staro sjeme; ako je pravi kvar bio izazov koji klijent nikada nije poslao, sada imate dvije promjene za objašnjenje umjesto jedne.

Držite sjeme i kodove za oporavak izvan kruga

Šest cifara i tajna iza njih nisu zamjenjivi. QR kod za dodjelu ili Base32 sjeme generiše svaki budući kod za račun, pa pripada istoj kategoriji kao lozinka: ne u snimku ekrana, ne u komentaru zahtjeva, ne u razgovoru s nekim ko se prvi javio vama. Kodovi za oporavak su odvojen mehanizam — jednokratni, često u potpunosti preskaču upit za kod, a trošenje jednog za test računa uklanja rezervni put koji vam može kasnije trebati.

Kod također ne čini stranicu za prijavu pouzdanom: upit za OTP na domeni sličnoj pravoj prikupi ispravan kod i ponovo ga pusti unutar prozora, a certifikat je i dalje ono što vam kaže gdje upisujete.

Ako slijed završi na profilu koji ne može odgovoriti na izazov, popravite profil i ponovo testirajte jednim svježim kodom. Ako završi na neusklađenim parametrima upisa, neka operater pročita zapis tokena prije nego iko bilo šta skenira. Ako završi na zaključavanju, sačekajte da prođe umjesto da mijenjate klijente — stanje računa je prepreka, ne aplikacija.