Varför en giltig engångskod ändå misslyckas vid VPN-inloggning

Du öppnar VPN-klienten, skriver in lösenordet, och de sex siffrorna från autentiseringsappen kommer tillbaka som ogiltiga — två gånger, sedan en tredje. Inget har ändrats på kontot sedan i går, så instinkten är att ta bort posten i autentiseringsappen och skanna den igen — oftast den felaktiga reparationen. En engångskod är inte ett andra lösenord: gatewayen måste fråga efter den i ett visst steg, från en viss registrerad post, inom ett visst tidsfönster, och de flesta avvisningar sker innan siffrorna jämförs. Ta reda på vilket steg du är i innan du rör registreringen.

Ordningen på förfrågningarna visar vilket flöde du är i

Tre former täcker nästan varje VPN-inloggning med en kod. I tvåstegsformen skickar klienten lösenordet, servern utfärdar en utmaning och klienten frågar igen. I den kombinerade formen vill gatewayen ha lösenord och kod i en enda inskickning — ibland sammankopplade, ibland efter en avgränsare som bara operatören dokumenterar. I webbläsarformen har klienten inget fält alls: koden går in på en webbsida, eller ett pushgodkännande ersätter den, och skrivbordsklienten väntar på resultatet.

Fel form ser ut som en dålig kod. Klistra in en färsk kod i ett fält som bara är för lösenordet, och servern läser den som en del av lösenordet. På klientsidan gör OpenVPN 2.4 och senare skillnaden synlig: en server som svarar med AUTH_FAILED,CRV1: förväntar sig ett utmaningssvar, så profilen behöver static-challenge eller en lösenordsfil i SCRV1:-form. En äldre profil med bara auth-user-pass autentiserar lösenordet och stannar sedan, vilket i loggen ser ut som ett OTP-fel trots att ingen kod skickades.

WireGuard förtjänar att nämnas som undantaget: det autentiserar nyckelpar i stället för människor, så det finns inget fält för en kod. Om en leverantör annonserar en är det något utanför tunneln som accepterar den.

Vad servern gör med de sex siffrorna

Tidsbaserade koder följer RFC 6238, som paketerar den äldre räknarbaserade konstruktionen från RFC 4226: en HMAC över en rörlig faktor, avkortad till sex siffror som standard. För TOTP är den rörliga faktorn aktuell Unix-tid delad med ett steg, 30 sekunder om inte operatören ändrat det. Verifieraren jämför aldrig dina siffror med ett lagrat värde; den räknar om den förväntade koden från det delade fröet och accepterar oftast även närliggande steg, så en långsam tur och retur får inte inloggningen att misslyckas.

Två konsekvenser förbises. Telefonens tidszon är irrelevant, eftersom fröet aldrig ser en lokal klocka — bara avvikelsen från den riktiga UTC spelar roll, och en enhet som går två minuter för fort misslyckas på varje kod medan den visar en ren nedräkning. Och en kod är engångs av design: verifieraren minns det senaste räknarvärde den accepterade för det fröet, så samma siffror som skickas igen avvisas även inom samma fönster. En klient som försöker igen efter en timeout kan bränna koden den just skickade.

Räknarbaserade tokens flyttar sin räknare vid varje tryckning, så de hamnar ur synk efter att koder genererats men aldrig skickats; den vanliga reparationen är ett omsynkroniseringsfönster som accepterar några värden framåt. Om operatören registrerade HOTP och din app visar TOTP är varje värde fel på ett sätt som ser ut som ett klockproblem. URI:n för etablering bakom QR-koden anger typ, siffror, period och hash.

Misslyckanden som ser ut som en felaktig kod

Den registrerade posten är den vanligaste boven. Autentiseringsappar märker poster med utgivare och konto, så den som har två identiteter på samma VPN kan få två poster vars etiketter skiljer sig med ett tecken. En kod är giltig för det frö som genererade den och inget annat. Jämför etiketten på telefonen med användarnamnet servern registrerar, inte med det du minns att du skrev.

Det andra är en parametermängd som inte passar. Ett frö registrerat med åtta siffror, en period på 60 sekunder eller SHA-256 ger koder som en verifierare som förväntar sig sex siffror, 30 sekunder och SHA-1 avvisar, och på klientsidan går det inte att skilja från en felaktig kod. Det dyker upp efter migreringar där posten lagts till igen från ett foto av QR-koden, eller där tokenposten byggts upp igen med standardvärden.

Det tredje handlar inte om koden. Gatewayer returnerar vanligtvis ett enda generiskt autentiseringsfel för fel lösenord, utgången kod och inaktiverat konto, med avsikt, så att ingen kan undersöka vilken faktor som misslyckades. Läs gateway- eller RADIUS-loggen i stället för klientens banderoll: en utmaning som aldrig utfärdades, en åtkomstvägran utan OTP-attribut och en policyvägran ser likadana ut på skärmen och leder till olika nästa steg.

En kort sekvens som snävar in det

Börja med den billigaste kontrollen och stanna vid det första steget som inte håller.

1. Vänta på en färsk kod, skicka den en gång och notera om utmaningen visas före eller efter att lösenordet godtas.
2. Matcha etiketten i autentiseringsappen mot användarnamnet som servern lagrar.
3. Bekräfta att profilen alls kan svara på en utmaning, som i CRV1-fallet ovan.
4. Jämför enhetens klocka med en känd tidskälla; en avvikelse på mer än några tiotal sekunder bryter TOTP i sig självt.
5. Fråga operatören om token är TOTP eller HOTP, och vilka siffror, period och hash som registrerades.

Två regler hindrar att detta gör saken värre. Försök inte igen många gånger: många gatewayer räknar misslyckanden per konto och låser det antingen eller börjar fördröja svar, så en skur förvandlar en liten felkonfiguration till en supportbiljett. Och registrera inte token igen som diagnostik, eftersom det ogiltiggör det gamla fröet; om det egentliga felet var en utmaning som klienten aldrig skickade har du nu två ändringar att förklara i stället för en.

Håll fröet och återställningskoderna utanför loopen

De sex siffrorna och hemligheten bakom dem är inte utbytbara. En etablerings-QR-kod eller ett Base32-frö genererar varje framtida kod för kontot, så det hör till samma kategori som lösenordet: inte i en skärmbild, inte i en biljettkommentar, inte i en chatt med någon som kontaktade dig först. Återställningskoder är en separat mekanism — engångs, hoppar ofta helt över kodfrågan, och att göra av med en för att testa kontot tar bort en reservväg du kan behöva senare.

En kod gör inte heller en inloggningssida pålitlig: en OTP-förfrågan på en liknande domän samlar in en giltig kod och spelar upp den inom fönstret, och certifikatet är fortfarande det som säger var du skriver.

Om sekvensen slutar på en profil som inte kan svara på en utmaning, rätta profilen och testa igen med en färsk kod. Om den slutar på parameterinställningar som inte passar, låt operatören läsa tokenposten innan någon skannar något. Om den slutar på en låsning, vänta ut den i stället för att byta klient — det är kontots tillstånd som blockerar, inte appen.