Pse një kod njëpërdorimësh i vlefshëm dështon gjithsesi në hyrjen në VPN

Hapni klientin VPN, shkruani fjalëkalimin, dhe gjashtë shifrat nga autentifikuesi kthehen si të pavlefshme — dy herë, pastaj herën e tretë. Asgjë nuk ka ndryshuar në llogari që nga dje, ndaj instinkti i parë është të fshini hyrjen në autentifikues dhe ta skanoni përsëri — zakonisht është rregullimi i gabuar. Një kod njëpërdorimësh nuk është fjalëkalim i dytë: porta duhet ta kërkojë atë në një hap të caktuar, nga një hyrje e regjistruar e caktuar, brenda një dritareje të caktuar, dhe shumica e refuzimeve ndodhin përpara se shifrat të krahasohen. Përcaktoni në cilin hap ndodheni përpara se të prekni regjistrimin.

Rendi i kërkesave ju tregon në cilin fluks jeni

Tri forma mbulojnë pothuajse çdo hyrje në VPN që përfshin një kod. Në formën me dy hapa klienti dërgon fjalëkalimin, serveri lëshon një sfidë dhe klienti pyet përsëri. Në formën e kombinuar porta kërkon fjalëkalimin dhe kodin në një dërgim të vetëm — ndonjëherë të bashkuar, ndonjëherë pas një ndarësi që dokumentohet vetëm nga operatori. Në formën e shfletuesit klienti nuk ka asnjë fushë: kodi shkon në një faqe web, ose një miratim push e zëvendëson atë, dhe klienti i desktopit pret rezultatin.

Forma e gabuar duket si kod i keq. Ngjitni një kod të freskët në një fushë vetëm për fjalëkalimin dhe serveri do ta lexojë si pjesë të fjalëkalimit. Nga ana e klientit, OpenVPN 2.4 dhe më i ri e bëjnë dallimin të dukshëm: një server që përgjigjet me AUTH_FAILED,CRV1: pret një përgjigje sfide, ndaj profili ka nevojë për static-challenge ose një skedar fjalëkalimi në formën SCRV1:. Një profil më i vjetër që mban vetëm auth-user-pass vërteton fjalëkalimin dhe pastaj ngec, gjë që në regjistër duket si dështim OTP edhe pse nuk u dërgua asnjë kod.

WireGuard meriton të përmendet si përjashtimi: vërteton çifte çelësash, jo njerëz, ndaj nuk ka fushë për një kod. Nëse një ofrues reklamon një të tillë, diçka jashtë tunelit po e pranon.

Çfarë bën serveri me gjashtë shifrat

Kodet e bazuara në kohë ndjekin RFC 6238, i cili mbështjell konstruksionin më të vjetër me numërues të RFC 4226: një HMAC mbi një faktor lëvizës, i shkurtuar në gjashtë shifra si parazgjedhje. Në TOTP faktori lëvizës është koha aktuale Unix e ndarë me një hap, 30 sekonda nëse operatori nuk e ka ndryshuar. Verifikuesi nuk i krahason kurrë shifrat tuaja me një vlerë të ruajtur; rillogarit kodin e pritur nga fara e përbashkët dhe zakonisht pranon edhe hapat fqinjë, kështu që një udhëtim i ngadaltë nuk e bën hyrjen të dështojë.

Dy pasoja anashkalohen. Zona kohore e telefonit është e parëndësishme, sepse fara nuk sheh kurrë orë lokale — rëndësi ka vetëm devijimi nga UTC i vërtetë, dhe një pajisje që shkon dy minuta përpara dështon në çdo kod ndërsa tregon një numërim mbrapsht të pastër. Dhe një kod është njëpërdorimësh sipas konstruksionit: verifikuesi mban mend vlerën e fundit të numëruesit që pranoi për atë farë, ndaj të njëjtat shifra të dërguara përsëri refuzohen edhe brenda të njëjtës dritare. Një klient që riprovoi pas skadimit mund të djegë kodin që sapo dërgoi.

Shenjat e bazuara në numërues e lëvizin numëruesin në çdo shtypje, ndaj dalin nga sinkronizimi pasi kodet janë krijuar por nuk janë dërguar kurrë; rregullimi i zakonshëm është një dritare risinkronizimi që pranon disa vlera përpara. Nëse operatori ka regjistruar HOTP dhe aplikacioni juaj tregon TOTP, çdo vlerë është e gabuar në një mënyrë që duket si problem ore. URI-ja e furnizimit pas kodit QR emërton llojin, shifrat, periudhën dhe hash-in.

Dështime që duken si kod i gabuar

Fajtori më i shpeshtë është hyrja e regjistruar. Aplikacionet e autentifikimit i etiketojnë hyrjet sipas lëshuesit dhe llogarisë, ndaj kush ka dy identitete në të njëjtin VPN mund të përfundojë me dy hyrje, etiketat e të cilave ndryshojnë me një karakter. Një kod është i vlefshëm për farën që e krijoi dhe për asgjë tjetër. Krahasoni etiketën në telefon me emrin e përdoruesit që regjistron serveri, jo me atë që ju kujtohet se keni shkruar.

E dyta është një grup parametrash që nuk përputhet. Një farë e regjistruar me tetë shifra, një periudhë 60 sekondash ose SHA-256 prodhon kode që një verifikues që pret gjashtë shifra, 30 sekonda dhe SHA-1 i refuzon, dhe nga klienti kjo nuk dallohet nga një kod i gabuar. Shfaqet pas migrimeve ku hyrja u shtua përsëri nga një fotografi e kodit QR, ose ku regjistri i shenjës u rindërtua me vlera të parazgjedhura.

E treta nuk ka të bëjë me kodin. Portat zakonisht kthejnë një dështim të përgjithshëm vërtetimi për fjalëkalim të gabuar, kod të skaduar dhe llogari të çaktivizuar, me qëllim, që askush të mos mund të hetojë cili faktor dështoi. Lexoni regjistrin e portës ose të RADIUS në vend të banerit të klientit: një sfidë që nuk u lëshua kurrë, një refuzim aksesi pa atribut OTP dhe një refuzim sipas politikës duken njësoj në ekran dhe çojnë në hapa të ndryshëm në vijim.

Një sekuencë e shkurtër që e ngushton

Filloni me kontrollin më të lirë dhe ndaloni në hapin e parë që nuk qëndron.

1. Prisni një kod të freskët, dërgojeni një herë dhe vini re nëse sfida shfaqet para ose pas pranimit të fjalëkalimit.
2. Përputhni etiketën në autentifikues me emrin e përdoruesit që ruan serveri.
3. Konfirmoni se profili mund të përgjigjet fare ndaj një sfide, si në rastin CRV1 më sipër.
4. Krahasoni orën e pajisjes me një burim të njohur kohe; një devijim mbi disa dhjetëra sekonda e prish TOTP në vetvete.
5. Pyetni operatorin nëse shenja është TOTP apo HOTP, dhe cilat shifra, periudhë dhe hash u regjistruan.

Dy rregulla pengojnë përkeqësimin. Mos riprovoni shumë herë: shumë porta numërojnë dështimet për llogari dhe ose e bllokojnë atë ose fillojnë të vonojnë përgjigjet, ndaj një valë e kthen një gabim të vogël konfigurimi në një biletë mbështetjeje. Dhe mos e riregjistroni shenjën si diagnostikim, sepse kjo e bën të pavlefshme farën e vjetër; nëse defekti i vërtetë ishte një sfidë që klienti nuk e dërgoi kurrë, tani keni dy ndryshime për të shpjeguar në vend të njërit.

Mbajeni farën dhe kodet e rikuperimit jashtë qarkut

Gjashtë shifrat dhe sekreti pas tyre nuk janë të këmbyeshëm. Një kod QR furnizimi ose një farë Base32 krijon çdo kod të ardhshëm të llogarisë, ndaj i përket të njëjtës kategori si fjalëkalimi: jo në një pamje ekrani, jo në një koment bilete, jo në një bisedë me dikë që ju kontaktoi i pari. Kodet e rikuperimit janë një mekanizëm më vete — njëpërdorimësh, shpesh e anashkalojnë plotësisht kërkesën për kod, dhe shpenzimi i njërit për të testuar llogarinë heq një rrugë rezervë që mund t'ju duhet më vonë.

Një kod nuk e bën as një faqe hyrjeje të besueshme: një kërkesë OTP në një domen të ngjashëm mbledh një kod të vlefshëm dhe e riprodhon brenda dritares, dhe certifikata është ende ajo që ju tregon se ku po shkruani.

Nëse sekuenca përfundon në një profil që nuk mund të përgjigjet ndaj një sfide, rregulloni profilin dhe ritestoni me një kod të freskët. Nëse përfundon në parametra regjistrimi që nuk përputhen, kërkojini operatorit të lexojë regjistrin e shenjës përpara se dikush të skanojë diçka. Nëse përfundon në një bllokim, prisni të kalojë në vend që të ndryshoni klientë — pengesa është gjendja e llogarisë, jo aplikacioni.