Proč platný jednorázový kód přesto selže při přihlášení k VPN

Otevřete klienta VPN, napíšete heslo a šest číslic z autentikátoru se vrátí jako neplatné — dvakrát, pak potřetí. Na účtu se od včerejška nic nezměnilo, takže instinkt je smazat záznam v autentikátoru a naskenovat ho znovu — obvykle špatná oprava. Jednorázový kód není druhé heslo: brána ho musí vyžádat v určitém kroku, z určitého registrovaného záznamu, v určitém okně, a většina odmítnutí nastane dřív, než se číslice porovnají. Zjistěte, v jakém kroku jste, než sáhnete na registraci.

Pořadí výzev ukazuje, v jakém toku jste

Tři podoby pokrývají téměř každé přihlášení k VPN, které zahrnuje kód. V dvoukrokové podobě klient odešle heslo, server vydá výzvu a klient se zeptá znovu. V kombinované podobě brána chce heslo i kód v jednom odeslání — někdy spojené, někdy za oddělovačem, který dokumentuje jen operátor. V prohlížečové podobě klient nemá žádné pole: kód jde na webovou stránku nebo ho nahradí push schválení a desktopový klient čeká na výsledek.

Špatná podoba vypadá jako špatný kód. Vložte čerstvý kód do pole určeného jen pro heslo a server ho přečte jako součást hesla. Na straně klienta OpenVPN 2.4 a novější rozdíl zviditelňují: server, který odpovídá AUTH_FAILED,CRV1:, očekává odpověď na výzvu, takže profil potřebuje static-challenge nebo soubor s heslem ve tvaru SCRV1:. Starší profil jen s auth-user-pass ověří heslo a pak se zasekne, což v logu vypadá jako selhání OTP, i když žádný kód nebyl odeslán.

WireGuard stojí za zmínku jako výjimka: ověřuje dvojice klíčů, ne lidi, takže pro kód nemá pole. Pokud poskytovatel nějaký inzeruje, přijímá ho něco mimo tunel.

Co server se šesti číslicemi dělá

Časové kódy následují RFC 6238, který obaluje starší konstrukci s čítačem z RFC 4226: HMAC nad pohyblivým faktorem, ve výchozím nastavení zkrácený na šest číslic. U TOTP je pohyblivým faktorem aktuální unixový čas dělený krokem, 30 sekund, pokud to operátor nezměnil. Ověřovatel nikdy neporovnává vaše číslice s uloženou hodnotou; přepočítá očekávaný kód ze sdíleného semene a obvykle přijme i sousední kroky, takže pomalá cesta tam a zpět přihlášení nepodkopne.

Dva důsledky se přehlížejí. Časové pásmo telefonu je irelevantní, protože semeno nikdy nevidí místní hodiny — záleží jen odchylka od skutečného UTC, a přístroj spěchající o dvě minuty selže u každého kódu, přitom ukazuje čisté odpočítávání. A kód je z principu jednorázový: ověřovatel si pamatuje poslední hodnotu čítače, kterou pro to semeno přijal, takže stejné číslice odeslané znovu se odmítnou i ve stejném okně. Klient, který to zkusí znovu po vypršení, může spálit kód, který právě odeslal.

Tokeny s čítačem posouvají čítač při každém stisku, takže se rozladí poté, co byly kódy vygenerovány, ale nikdy odeslány; obvyklá oprava je okno resynchronizace, které přijímá několik hodnot dopředu. Pokud operátor zaregistroval HOTP a vaše aplikace zobrazuje TOTP, každá hodnota je špatná způsobem, který vypadá jako problém s hodinami. URI zřizování za QR kódem udává typ, číslice, periodu a hash.

Selhání, která vypadají jako špatný kód

Registrovaný záznam je nejčastější viník. Autentikační aplikace označují záznamy podle vydavatele a účtu, takže kdo má na stejné VPN dvě identity, může skončit se dvěma záznamy, jejichž označení se liší o jeden znak. Kód platí pro semeno, které ho vygenerovalo, a pro nic jiného. Porovnejte označení v telefonu s uživatelským jménem, které server zaznamenává, ne s tím, co si pamatujete, že jste napsali.

Druhá je neodpovídající sada parametrů. Semeno registrované s osmi číslicemi, periodou 60 sekund nebo SHA-256 dává kódy, které ověřovatel očekávající šest číslic, 30 sekund a SHA-1 odmítne, a u klienta to nelze rozeznat od špatného kódu. Objevuje se po migracích, kdy byl záznam znovu přidán z fotografie QR kódu, nebo kdy byl záznam tokenu přestavěn s výchozími hodnotami.

Třetí není o kódu. Brány obvykle vracejí jedno obecné selhání ověření pro špatné heslo, propadlý kód i deaktivovaný účet, záměrně, aby nikdo nemohl zjistit, který faktor selhal. Čtěte log brány nebo RADIUS místo hlášky klienta: výzva, která nikdy nebyla vydána, odmítnutí přístupu bez atributu OTP a odmítnutí politikou vypadají na obrazovce stejně a vedou k různým dalším krokům.

Krátká posloupnost, která to zúží

Začněte nejlevnější kontrolou a zastavte se u prvního kroku, který neobstojí.

1. Počkejte na čerstvý kód, odešlete ho jednou a poznamenejte si, zda se výzva objeví před přijetím hesla, nebo po něm.
2. Porovnejte označení v autentikátoru s uživatelským jménem, které server ukládá.
3. Ověřte, že profil vůbec dokáže odpovědět na výzvu, jako v případě CRV1 výše.
4. Porovnejte hodiny zařízení se známým zdrojem času; odchylka větší než několik desítek sekund sama rozbije TOTP.
5. Zeptejte se operátora, zda je token TOTP, nebo HOTP, a které číslice, perioda a hash byly zaregistrovány.

Dvě pravidla brání tomu, aby se to zhoršilo. Neopakujte pokus mnohokrát: mnoho bran počítá selhání na účet a buď ho zamkne, nebo začne zdržovat odpovědi, takže nával promění malou chybu v konfiguraci v tiket podpory. A nepřeregistrujte token jako diagnostiku, protože to zneplatní staré semeno; pokud byla skutečná závada výzvou, kterou klient nikdy neodeslal, máte nyní dvě změny k vysvětlení místo jedné.

Držte semeno a obnovovací kódy mimo hru

Šest číslic a tajemství za nimi nejsou zaměnitelné. Zřizovací QR kód nebo semeno Base32 generuje každý budoucí kód účtu, takže patří do stejné kategorie jako heslo: ne do screenshotu, ne do komentáře tiketu, ne do chatu s někým, kdo se ozval první. Obnovovací kódy jsou samostatný mechanismus — jednorázové, často úplně přeskakují výzvu ke kódu, a utracení jednoho na test účtu odstraní záložní cestu, kterou můžete později potřebovat.

Kód také nedělá přihlašovací stránku důvěryhodnou: výzva k OTP na podobné doméně posbírá platný kód a přehraje ho uvnitř okna, a certifikát je pořád to, co vám říká, kam píšete.

Pokud posloupnost skončí u profilu, který neumí odpovědět na výzvu, opravte profil a otestujte znovu jedním čerstvým kódem. Pokud skončí u neodpovídajících registračních parametrů, nechte operátora přečíst záznam tokenu, než kdokoli něco naskenuje. Pokud skončí u uzamčení, vyčkejte ho, místo abyste měnili klienty — překážkou je stav účtu, ne aplikace.