Waarom 'n geldige eenmalige kode steeds by VPN-aanmelding misluk

Jy maak die VPN-kliënt oop, tik die wagwoord in, en die ses syfers van jou verifikasieprogram kom terug as ongeldig — twee keer, dan 'n derde keer. Niks het sedert gister op die rekening verander nie, so die instink is om die inskrywing in die verifikasieprogram te skrap en weer te skandeer — gewoonlik die verkeerde herstelling. 'n Eenmalige kode is nie 'n tweede wagwoord nie: die poort moet dit in 'n spesifieke stap vra, uit 'n spesifieke ingeskrewe inskrywing, binne 'n spesifieke venster, en die meeste afkeurings gebeur voordat die syfers vergelyk word. Bepaal in watter stap jy is voordat jy aan die inskrywing raak.

Die volgorde van die vrae wys watter vloei jy volg

Drie vorms dek byna elke VPN-aanmelding waarby 'n kode betrokke is. In die tweestapvorm stuur die kliënt die wagwoord, die bediener lewer 'n uitdaging, en die kliënt vra weer. In die gekombineerde vorm wil die poort die wagwoord en die kode in een voorlegging hê — soms aanmekaar, soms ná 'n skeier wat net die operateur dokumenteer. In die blaaiervorm het die kliënt glad geen veld nie: die kode gaan in 'n webblad in, of 'n stootgoedkeuring vervang dit, en die lessenaarkliënt wag vir die uitslag.

Om die vorm verkeerd te kry, lyk soos 'n slegte kode. Plak 'n vars kode in 'n veld wat net vir die wagwoord bedoel is, en die bediener lees dit as deel van die wagwoord. Aan die kliëntkant maak OpenVPN 2.4 en later die verskil sigbaar: 'n bediener wat met AUTH_FAILED,CRV1: antwoord, verwag 'n uitdagingsantwoord, so die profiel het static-challenge nodig of 'n wagwoordlêer in SCRV1:-vorm. 'n Ouer profiel wat net auth-user-pass het, verifieer die wagwoord en staan dan vas, wat in die log soos 'n OTP-fout lyk al is daar geen kode gestuur nie.

WireGuard is die moeite werd om as die uitsondering te noem: dit verifieer sleutelpare eerder as mense, so daar is geen veld vir 'n kode nie. As 'n verskaffer een adverteer, is dit iets buite die tonnel wat dit aanvaar.

Wat die bediener met die ses syfers doen

Tydgebaseerde kodes volg RFC 6238, wat die ouer tellergebaseerde konstruksie uit RFC 4226 omhul: 'n HMAC oor 'n bewegende faktor, by verstek tot ses syfers afgekap. Vir TOTP is die bewegende faktor die huidige Unix-tyd gedeel deur 'n stap, 30 sekondes tensy die operateur dit verander het. Die verifieerder vergelyk nooit jou syfers met 'n gestoorde waarde nie; dit herbereken die verwagte kode uit die gedeelde saad en aanvaar gewoonlik ook die naburige stappe, so 'n stadige rondreis laat die aanmelding nie misluk nie.

Twee gevolge word misgekyk. Die selfoon se tydsone is irrelevant, want die saad sien nooit 'n plaaslike horlosie nie — net die afwyking van die werklike UTC maak saak, en 'n handtoestel wat twee minute vinnig loop, laat elke kode misluk terwyl dit 'n skoon aftelling wys. En 'n kode is per ontwerp eenmalig: die verifieerder onthou die laaste tellerwaarde wat dit vir daardie saad aanvaar het, so dieselfde syfers wat weer ingedien word, word verwerp selfs binne dieselfde venster. 'n Kliënt wat ná 'n tydverstryking weer probeer, kan die kode wat hy pas gestuur het, opgebruik.

Tellergebaseerde tekens skuif hul teller by elke druk, so hulle raak uit pas ná kodes gegenereer is maar nooit ingedien is nie; die gewone herstelling is 'n hersinchroniseringsvenster wat 'n paar waardes vorentoe aanvaar. As die operateur HOTP ingeskryf het en jou toepassing wys TOTP, is elke waarde verkeerd op 'n manier wat soos 'n horlosieprobleem lyk. Die voorsienings-URI agter die QR-kode noem die tipe, syfers, tydperk en hash.

Mislukkings wat soos 'n verkeerde kode lyk

Die ingeskrewe inskrywing is die mees algemene oorsaak. Verifikasieprogramme benoem inskrywings volgens uitreiker en rekening, so enigiemand met twee identiteite op dieselfde VPN kan twee inskrywings kry waarvan die name met een karakter verskil. 'n Kode is geldig vir die saad wat dit gegenereer het en vir niks anders nie. Vergelyk die naam op die selfoon met die gebruikersnaam wat die bediener registreer, nie met wat jy onthou jy getik het nie.

Tweedens is daar 'n stel parameters wat nie pas nie. 'n Saad wat met agt syfers, 'n tydperk van 60 sekondes of SHA-256 ingeskryf is, lewer kodes wat 'n verifieerder wat ses syfers, 30 sekondes en SHA-1 verwag, weier, en by die kliënt is dit nie van 'n verkeerde kode te onderskei nie. Dit verskyn ná migrasies waar die inskrywing uit 'n foto van die QR-kode weer bygevoeg is, of waar die tekenrekord met verstekwaardes herbou is.

Derdens gaan dit nie oor die kode nie. Poorte gee gewoonlik een generiese verifikasiefout vir 'n verkeerde wagwoord, 'n kode wat verval het en 'n gedeaktiveerde rekening, doelbewus, sodat niemand kan peil watter faktor gefaal het nie. Lees eerder die poort- of RADIUS-log as die kliënt se banier: 'n uitdaging wat nooit uitgereik is nie, 'n toegang-weiering sonder 'n OTP-kenmerk en 'n beleidsweiering lyk alles dieselfde op die skerm en lei tot verskillende volgende stappe.

'n Kort reeks wat dit vernou

Begin met die goedkoopste kontrole en stop by die eerste stap wat nie klop nie.

1. Wag vir 'n vars kode, dien dit een keer in, en let op of die uitdaging voor of ná die aanvaarding van die wagwoord verskyn.
2. Vergelyk die naam in die verifikasieprogram met die gebruikersnaam wat die bediener stoor.
3. Bevestig dat die profiel hoegenaamd 'n uitdaging kan antwoord, soos in die CRV1-geval hierbo.
4. Vergelyk die toestel se horlosie met 'n bekende tydbron; 'n afwyking van meer as 'n paar tien sekondes laat TOTP op sy eie misluk.
5. Vra die operateur of die teken TOTP of HOTP is, en watter syfers, tydperk en hash ingeskryf is.

Twee reëls verhoed dat dit dinge erger maak. Moenie baie keer weer probeer nie: baie poorte tel mislukkings per rekening en sluit dit óf begin response vertraag, so 'n uitbarsting verander 'n klein miskonfigurasie in 'n ondersteuningskaartjie. En moenie die teken as diagnose herinskryf nie, want dit maak die ou saad ongeldig; as die werklike fout 'n uitdaging was wat die kliënt nooit gestuur het nie, het jy nou twee veranderinge om te oorweeg in plaas van een.

Hou die saad en die herstelkodes buite die spel

Die ses syfers en die geheim daarby is nie uitruilbaar nie. 'n Voorsienings-QR-kode of 'n Base32-saad genereer elke toekomstige kode vir die rekening, so dit hoort in dieselfde kategorie as die wagwoord: nie in 'n skermkopie nie, nie in 'n kaartjiekommentaar nie, nie in 'n gesprek met iemand wat jou eerste gekontak het nie. Herstelkodes is 'n aparte meganisme — eenmalig, dikwels word die kodevra heeltemal oorgeslaan, en om een te spandeer om die rekening te toets, verwyder 'n terugval wat jy later mag nodig hê.

'n Kode maak ook nie 'n aanmeldbladsy betroubaar nie: 'n OTP-vra op 'n namaakseldomein versamel 'n geldige kode en speel dit binne die venster terug, en die sertifikaat is steeds wat jou vertel waar jy tik.

As die reeks by 'n profiel beland wat nie 'n uitdaging kan antwoord nie, maak die profiel reg en toets weer met een vars kode. As dit by parameters beland wat nie pas nie, laat die operateur die tekenrekord lees voordat iemand enigiets skandeer. As dit by 'n uitsluiting beland, wag dit uit eerder as om kliënte te ruil — die rekeningtoestand is die versperring, nie die toepassing nie.