Hvorfor en gyldig engangskode likevel feiler ved VPN-innlogging

Du åpner VPN-klienten, skriver inn passordet, og de seks sifrene fra autentiseringsappen kommer tilbake som ugyldige — to ganger, deretter en tredje. Ingenting er endret på kontoen siden i går, så instinktet er å slette oppføringen i autentiseringsappen og skanne den på nytt — som regel den gale reparasjonen. En engangskode er ikke et ekstra passord: gatewayen må be om den i et bestemt trinn, fra en bestemt registrert oppføring, innenfor et bestemt tidsvindu, og de fleste avvisninger skjer før sifrene sammenlignes. Finn ut hvilket trinn du er i før du rører registreringen.

Rekkefølgen av forespørsler viser hvilken flyt du er i

Tre former dekker nesten hver VPN-innlogging med en kode. I to-trinnsformen sender klienten passordet, serveren utsteder en utfordring, og klienten spør igjen. I den kombinerte formen vil gatewayen ha passord og kode i én innsending — noen ganger sammenkoblet, noen ganger etter en separator som bare operatøren dokumenterer. I nettleserformen har klienten ikke noe felt i det hele tatt: koden går inn på en nettside, eller en push-godkjenning erstatter den, og skrivebordsklienten venter på resultatet.

Feil form ser ut som en dårlig kode. Lim inn en fersk kode i et felt som bare er for passordet, og serveren leser den som en del av passordet. På klientsiden gjør OpenVPN 2.4 og nyere forskjellen synlig: en server som svarer med AUTH_FAILED,CRV1: forventer et utfordringssvar, så profilen trenger static-challenge eller en passordfil i SCRV1:-form. En eldre profil som bare har auth-user-pass, godkjenner passordet og stopper deretter, noe som i loggen ser ut som en OTP-feil selv om ingen kode ble sendt.

WireGuard fortjener å bli nevnt som unntaket: den autentiserer nøkkelpar i stedet for personer, så det finnes ikke noe felt for en kode. Hvis en leverandør annonserer en, er det noe utenfor tunnelen som aksepterer den.

Hva serveren gjør med de seks sifrene

Tidsbaserte koder følger RFC 6238, som pakker inn den eldre tellerbaserte konstruksjonen fra RFC 4226: en HMAC over en flyttende faktor, avkortet til seks sifre som standard. For TOTP er den flyttende faktoren gjeldende Unix-tid delt på et trinn, 30 sekunder med mindre operatøren har endret det. Verifikatoren sammenligner aldri sifrene dine med en lagret verdi; den regner ut den forventede koden på nytt fra det delte frøet og godtar vanligvis også nabotrinnene, så en treg rundtur får ikke innloggingen til å feile.

To konsekvenser overses. Telefonens tidssone er irrelevant, fordi frøet aldri ser en lokal klokke — bare avviket fra den ekte UTC teller, og en håndsett som går to minutter for fort feiler på hver kode mens den viser en ren nedtelling. Og en kode er engangs av design: verifikatoren husker den siste tellerverdien den godtok for det frøet, så de samme sifrene som sendes inn igjen, avvises selv innenfor samme vindu. En klient som prøver på nytt etter en tidsavbrudd, kan brenne koden den nettopp sendte.

Tellerbaserte tokens flytter telleren ved hvert trykk, så de kommer ut av synkronisering etter at koder er generert, men aldri sendt; den vanlige reparasjonen er et resynkroniseringsvindu som godtar noen få verdier fremover. Hvis operatøren registrerte HOTP og appen din viser TOTP, er hver verdi feil på en måte som ser ut som et klokkeproblem. URI-en for klargjøring bak QR-koden navngir typen, sifrene, perioden og hashen.

Feil som ser ut som en feil kode

Den registrerte oppføringen er den vanligste årsaken. Autentiseringsapper merker oppføringer med utsteder og konto, så den som har to identiteter på samme VPN, kan ende opp med to oppføringer der merkene skiller seg med ett tegn. En kode er gyldig for frøet som genererte den, og for ingenting annet. Sammenlign merket på telefonen med brukernavnet serveren registrerer, ikke med det du husker at du skrev.

Det andre er et parametersett som ikke passer. Et frø registrert med åtte sifre, en periode på 60 sekunder eller SHA-256 gir koder som en verifikator som forventer seks sifre, 30 sekunder og SHA-1 avviser, og på klientsiden kan det ikke skilles fra en feil kode. Det dukker opp etter migreringer der oppføringen ble lagt til på nytt fra et bilde av QR-koden, eller der tokenoppføringen ble bygget opp igjen med standardverdier.

Det tredje handler ikke om koden. Gatewayer returnerer vanligvis én generisk autentiseringsfeil for feil passord, utløpt kode og deaktivert konto, med vilje, slik at ingen kan undersøke hvilken faktor som feilet. Les gateway- eller RADIUS-loggen i stedet for klientens banner: en utfordring som aldri ble utstedt, en tilgangsavvisning uten OTP-attributt og en policyavvisning ser like ut på skjermen og fører til ulike neste steg.

En kort sekvens som snevrer det inn

Start med den billigste kontrollen, og stopp ved det første trinnet som ikke holder.

1. Vent på en fersk kode, send den én gang, og noter om utfordringen vises før eller etter at passordet godtas.
2. Sammenlign merket i autentiseringsappen med brukernavnet serveren lagrer.
3. Bekreft at profilen i det hele tatt kan svare på en utfordring, som i CRV1-tilfellet ovenfor.
4. Sammenlign enhetens klokke med en kjent tidskilde; et avvik på mer enn noen titalls sekunder ødelegger TOTP i seg selv.
5. Spør operatøren om tokenet er TOTP eller HOTP, og hvilke sifre, periode og hash som ble registrert.

To regler hindrer at dette gjør tingene verre. Ikke prøv igjen mange ganger: mange gatewayer teller feil per konto og låser den enten eller begynner å forsinke svar, så en byge gjør en liten feilkonfigurasjon om til en støttebillett. Og ikke registrer tokenet på nytt som diagnose, for det ugyldiggjør det gamle frøet; hvis den egentlige feilen var en utfordring klienten aldri sendte, har du nå to endringer å forklare i stedet for én.

Hold frøet og gjenopprettingskodene utenfor spill

De seks sifrene og hemmeligheten bak dem kan ikke byttes om. En klargjørings-QR-kode eller et Base32-frø genererer hver fremtidige kode for kontoen, så det hører i samme kategori som passordet: ikke i et skjermbilde, ikke i en saksomtale, ikke i en chat med noen som tok kontakt først. Gjenopprettingskoder er en egen mekanisme — engangs, hopper ofte helt over kodeprompten, og bruker du én på å teste kontoen, fjerner du en reservevei du kanskje trenger senere.

En kode gjør heller ikke en innloggingsside til å stole på: en OTP-forespørsel på et lignende domene samler inn en gyldig kode og spiller den av igjen innenfor vinduet, og sertifikatet er fortsatt det som forteller deg hvor du skriver.

Hvis sekvensen ender på en profil som ikke kan svare på en utfordring, rett profilen og test på nytt med én fersk kode. Hvis den ender på parameterinnstillinger som ikke passer, la operatøren lese tokenoppføringen før noen skanner noe. Hvis den ender på en låsing, vent den ut i stedet for å bytte klient — det er kontotilstanden som blokkerer, ikke appen.