Kvifor ein gyldig eingongskode likevel feilar ved VPN-innlogging

Du opnar VPN-klienten, skriv inn passordet, og dei seks sifra frå autentiseringsappen kjem tilbake som ugyldige — to gonger, deretter ein tredje. Ingenting er endra på kontoen sidan i går, så instinktet er å slette oppføringa i autentiseringsappen og skanne ho på nytt — som regel den gale reparasjonen. Ein eingongskode er ikkje eit ekstra passord: gatewayen må be om han i eit bestemt trinn, frå ei bestemt registrert oppføring, innanfor eit bestemt tidsvindauge, og dei fleste avvisingar skjer før sifra blir samanlikna. Finn ut kva trinn du er i før du rører registreringa.

Rekkjefølgja av førespurnader viser kva flyt du er i

Tre former dekkjer nesten kvar VPN-innlogging med ein kode. I to-trinnsforma sender klienten passordet, serveren gjev ut ei utfordring, og klienten spør igjen. I den kombinerte forma vil gatewayen ha passord og kode i éi innsending — nokre gonger samankopla, nokre gonger etter ein separator som berre operatøren dokumenterer. I nettlesarforma har klienten ikkje noko felt i det heile: koden går inn på ei nettside, eller ei push-godkjenning erstattar han, og skrivebordsklienten ventar på resultatet.

Feil form ser ut som ein dårleg kode. Lim inn ein fersk kode i eit felt som berre er for passordet, og serveren les han som ein del av passordet. På klientsida gjer OpenVPN 2.4 og nyare skilnaden synleg: ein server som svarar med AUTH_FAILED,CRV1: ventar eit utfordringssvar, så profilen treng static-challenge eller ei passordfil i SCRV1:-form. Ein eldre profil som berre har auth-user-pass, godkjenner passordet og stoppar deretter, noko som i loggen ser ut som ein OTP-feil sjølv om ingen kode vart send.

WireGuard fortener å bli nemnd som unntaket: han autentiserer nøkkelpar i staden for personar, så det finst ikkje noko felt for ein kode. Viss ein leverandør annonserer ein, er det noko utanfor tunnelen som godtek han.

Kva serveren gjer med dei seks sifra

Tidsbaserte kodar følgjer RFC 6238, som pakkar inn den eldre teljarbaserte konstruksjonen frå RFC 4226: ein HMAC over ein flyttande faktor, avkorta til seks siffer som standard. For TOTP er den flyttande faktoren gjeldande Unix-tid delt på eit trinn, 30 sekund med mindre operatøren har endra det. Verifikatoren samanliknar aldri sifra dine med ein lagra verdi; han reknar ut den forventa koden på nytt frå det delte frøet og godtek vanlegvis òg nabotrinna, så ein treg rundtur får ikkje innlogginga til å feile.

To konsekvensar blir oversedde. Tidssona til telefonen er irrelevant, fordi frøet aldri ser ei lokal klokke — berre avviket frå den ekte UTC tel, og eit handsett som går to minutt for fort feilar på kvar kode medan det viser ei rein nedteljing. Og ein kode er eingongs av design: verifikatoren hugsar den siste teljarverdien han godtok for det frøet, så dei same sifra som blir sende inn igjen, blir avviste sjølv innanfor same vindauge. Ein klient som prøver på nytt etter ein tidsavbrot, kan brenne koden han nettopp sende.

Teljarbaserte token flyttar teljaren ved kvart trykk, så dei kjem ut av synkronisering etter at kodar er genererte, men aldri sende; den vanlege reparasjonen er eit resynkroniseringsvindauge som godtek nokre få verdiar framover. Viss operatøren registrerte HOTP og appen din viser TOTP, er kvar verdi feil på ein måte som ser ut som eit klokkeproblem. URI-en for klargjering bak QR-koden namngjev typen, sifra, perioden og hashen.

Feil som ser ut som ein feil kode

Den registrerte oppføringa er den vanlegaste årsaka. Autentiseringsappar merkar oppføringar med utferdar og konto, så den som har to identitetar på same VPN, kan ende opp med to oppføringar der merka skil seg med eitt teikn. Ein kode er gyldig for frøet som genererte han, og for ingenting anna. Samanlikn merket på telefonen med brukarnamnet serveren registrerer, ikkje med det du hugsar at du skreiv.

Det andre er eit parametersett som ikkje passar. Eit frø registrert med åtte siffer, ein periode på 60 sekund eller SHA-256 gjev kodar som ein verifikator som ventar seks siffer, 30 sekund og SHA-1 avviser, og på klientsida kan det ikkje skiljast frå ein feil kode. Det dukkar opp etter migreringar der oppføringa vart lagd til på nytt frå eit bilete av QR-koden, eller der tokenoppføringa vart bygd opp igjen med standardverdiar.

Det tredje handlar ikkje om koden. Gatewayar returnerer vanlegvis éin generisk autentiseringsfeil for feil passord, utlopen kode og deaktivert konto, med vilje, slik at ingen kan undersøkje kva faktor som feila. Les gateway- eller RADIUS-loggen i staden for banneret til klienten: ei utfordring som aldri vart gjeven ut, ei tilgangsavvising utan OTP-attributt og ei policyavvising ser like ut på skjermen og fører til ulike neste steg.

Ein kort sekvens som snevrar det inn

Start med den billegaste kontrollen, og stopp ved det første trinnet som ikkje held.

1. Vent på ein fersk kode, send han éin gong, og noter om utfordringa viser seg før eller etter at passordet blir godtatt.
2. Samanlikn merket i autentiseringsappen med brukarnamnet serveren lagrar.
3. Stadfest at profilen i det heile kan svare på ei utfordring, som i CRV1-tilfellet ovanfor.
4. Samanlikn klokka til eininga med ein kjend tidskjelde; eit avvik på meir enn nokre titals sekund øydelegg TOTP i seg sjølv.
5. Spør operatøren om tokenet er TOTP eller HOTP, og kva siffer, periode og hash som vart registrerte.

To reglar hindrar at dette gjer tinga verre. Ikkje prøv igjen mange gonger: mange gatewayar tel feil per konto og låser han anten eller byrjar å forseinke svar, så ein byge gjer ein liten feilkonfigurasjon om til ein støttebillett. Og ikkje registrer tokenet på nytt som diagnose, for det gjer det gamle frøet ugyldig; viss den eigentlege feilen var ei utfordring klienten aldri sende, har du no to endringar å forklare i staden for éi.

Hald frøet og gjenopprettingskodane utanfor spelet

Dei seks sifra og hemmelegheita bak dei kan ikkje bytast om. Ein klargjerings-QR-kode eller eit Base32-frø genererer kvar framtidige kode for kontoen, så det høyrer i same kategori som passordet: ikkje i eit skjermbilete, ikkje i ein saksomtale, ikkje i ein chat med nokon som tok kontakt først. Gjenopprettingskodar er ein eigen mekanisme — eingongs, hoppar ofte heilt over kodeprompten, og brukar du éin på å teste kontoen, fjernar du ein reserveveg du kanskje treng seinare.

Ein kode gjer heller ikkje ei innloggingsside til å stola på: ein OTP-førespurnad på eit liknande domene samlar inn ein gyldig kode og spelar han av igjen innanfor vindauget, og sertifikatet er framleis det som fortel deg kvar du skriv.

Viss sekvensen endar på ein profil som ikkje kan svare på ei utfordring, rett profilen og test på nytt med éin fersk kode. Viss han endar på parameterinnstillingar som ikkje passar, la operatøren lese tokenoppføringa før nokon skannar noko. Viss han endar på ei låsing, vent han ut i staden for å bytte klient — det er kontotilstanden som blokkerer, ikkje appen.