Miért hiúsul meg mégis egy érvényes egyszeri kód a VPN-bejelentkezésnél

Megnyitja a VPN-klienst, beírja a jelszót, és a hitelesítő hat számjegye érvénytelenként jön vissza — kétszer, majd harmadszorra. A fiókon semmi sem változott tegnap óta, ezért a reflex az, hogy törölje a bejegyzést a hitelesítőben, és újra beszkennelje — általában ez a rossz javítás. Az egyszeri kód nem második jelszó: az átjárónak egy adott lépésben, egy adott regisztrált bejegyzésből, egy adott ablakon belül kell kérnie, és az elutasítások többsége még a számjegyek összehasonlítása előtt történik. Állapítsa meg, melyik lépésben van, mielőtt a regisztrációhoz nyúl.

A kérések sorrendje megmondja, melyik folyamatban van

Három forma fedi le szinte az összes kódot tartalmazó VPN-bejelentkezést. A kétlépéses formában a kliens elküldi a jelszót, a szerver kihívást ad ki, és a kliens újra kérdez. A kombinált formában az átjáró a jelszót és a kódot egyetlen beküldésben kéri — néha összefűzve, néha olyan elválasztó után, amelyet csak az üzemeltető dokumentál. A böngészős formában a kliensnek egyáltalán nincs mezője: a kód egy weboldalra kerül, vagy push-jóváhagyás váltja fel, és az asztali kliens várja az eredményt.

A rossz forma rossz kódnak látszik. Illesszen friss kódot egy csak jelszónak szánt mezőbe, és a szerver a jelszó részeként olvassa. A kliens oldalán az OpenVPN 2.4 és újabb változatai láthatóvá teszik a különbséget: az AUTH_FAILED,CRV1: választ adó szerver kihívásválaszt vár, ezért a profilnak static-challenge vagy SCRV1: formájú jelszófájl kell. Egy régebbi, csak auth-user-pass bejegyzést tartalmazó profil hitelesíti a jelszót, majd megáll, ami a naplóban OTP-hibának látszik, pedig nem küldtek kódot.

A WireGuardot érdemes kivételként említeni: kulcspárokat hitelesít, nem embereket, ezért nincs mező a kódnak. Ha egy szolgáltató mégis hirdet ilyet, valami az alagúton kívül fogadja el.

Mit tesz a szerver a hat számjeggyel

Az időalapú kódok a RFC 6238-at követik, amely az RFC 4226 régebbi számlálóalapú konstrukcióját csomagolja: HMAC egy mozgó tényező fölött, alapértelmezésben hat számjegyre vágva. A TOTP-nál a mozgó tényező az aktuális Unix-idő egy lépéssel osztva, 30 másodperc, hacsak az üzemeltető nem változtatta meg. Az ellenőrző soha nem hasonlítja a számjegyeket tárolt értékhez; újraszámolja a várt kódot a közös magból, és általában a szomszédos lépéseket is elfogadja, így a lassú oda-vissza út nem buktatja meg a bejelentkezést.

Két következmény marad észrevétlen. A telefon időzónája irreleváns, mert a mag soha nem lát helyi órát — csak a valódi UTC-től való eltérés számít, és a két perccel előre járó készülék minden kódnál elbukik, miközben tiszta visszaszámlálást mutat. A kód pedig tervezésénél fogva egyszer használatos: az ellenőrző emlékszik az utolsó elfogadott számlálóértékre az adott maghoz, ezért ugyanazok a számjegyek újraküldve még ugyanazon az ablakon belül is elutasításra kerülnek. Az időtúllépés után újrapróbálkozó kliens elégetheti az imént elküldött kódot.

A számlálóalapú tokenek minden nyomáskor továbbléptetik a számlálót, ezért kiesnek a szinkronból, miután kódok generálódtak, de soha nem küldték el őket; a szokásos javítás egy újraszinkronizálási ablak, amely néhány értéket előre elfogad. Ha az üzemeltető HOTP-t regisztrált, az alkalmazása pedig TOTP-t mutat, minden érték hibás oly módon, ami óraproblémának látszik. A QR-kód mögötti kiépítési URI megnevezi a típust, a számjegyeket, a periódust és a hasht.

Rossz kódnak látszó hibák

A regisztrált bejegyzés a leggyakoribb bűnös. A hitelesítő alkalmazások a bejegyzéseket kibocsátó és fiók szerint címkézik, ezért akinek két identitása van ugyanazon a VPN-en, két olyan bejegyzéshez juthat, amelyek címkéje egy karakterben különbözik. A kód csak azt a magot illeti, amely létrehozta, és semmi mást. Hasonlítsa össze a telefonon látható címkét a szerver által rögzített felhasználónévvel, ne azzal, amire emlékszik, hogy beírta.

Másodszor egy nem illeszkedő paraméterkészlet. A nyolc számjeggyel, 60 másodperces periódussal vagy SHA-256-tal regisztrált mag olyan kódokat ad, amelyeket a hat számjegyet, 30 másodpercet és SHA-1-et váró ellenőrző elutasít, és a kliensnél ez megkülönböztethetetlen a rossz kódtól. Migrációk után jelenik meg, amikor a bejegyzést a QR-kód fényképéről újra hozzáadták, vagy amikor a tokenrekordot alapértékekkel újraépítették.

Harmadszor nem a kódról van szó. Az átjárók általában egyetlen általános hitelesítési hibát adnak vissza rossz jelszóra, lejárt kódra és letiltott fiókra, szándékosan, hogy senki ne tudja kipuhatolni, melyik tényező hibázott. A kliens szalagcím helyett az átjáró vagy a RADIUS naplóját olvassa: a soha ki nem adott kihívás, az OTP-attribútum nélküli hozzáférés-elutasítás és a házirend szerinti elutasítás ugyanúgy néz ki a képernyőn, és különböző következő lépésekhez vezet.

Egy rövid sorrend, amely szűkíti

Kezdje a legolcsóbb ellenőrzéssel, és álljon meg az első lépésnél, amely nem állja meg a helyét.

1. Várjon friss kódra, küldje be egyszer, és jegyezze fel, hogy a kihívás a jelszó elfogadása előtt vagy után jelenik-e meg.
2. Párosítsa a hitelesítőben lévő címkét a szerver által tárolt felhasználónévhez.
3. Erősítse meg, hogy a profil egyáltalán képes válaszolni a kihívásra, mint a fenti CRV1 esetben.
4. Hasonlítsa össze az eszköz óráját egy ismert időforrással; a néhány tíz másodpercnél nagyobb eltérés önmagában megtöri a TOTP-t.
5. Kérdezze meg az üzemeltetőt, hogy a token TOTP vagy HOTP, és milyen számjegyeket, periódust és hasht regisztráltak.

Két szabály akadályozza meg, hogy ez elmérgesedjen. Ne próbálkozzon sokszor: sok átjáró fiókonként számolja a hibákat, és vagy zárolja, vagy elkezdi késleltetni a válaszokat, így egy roham apró konfigurációs hibát támogatási jeggyé változtat. És ne regisztrálja újra a tokent diagnózisként, mert az érvényteleníti a régi magot; ha a valódi hiba egy olyan kihívás volt, amelyet a kliens soha nem küldött el, most két változást kell megmagyaráznia egy helyett.

Tartsa a magot és a helyreállítási kódokat a körön kívül

A hat számjegy és a mögöttük lévő titok nem felcserélhető. A kiépítési QR-kód vagy a Base32-mag létrehozza a fiók minden jövőbeli kódját, ezért ugyanabba a kategóriába tartozik, mint a jelszó: nem képernyőképen, nem jegy megjegyzésében, nem olyan csevegésben, ahol a másik fél keresett meg először. A helyreállítási kódok külön mechanizmus — egyszer használatosak, gyakran teljesen kihagyják a kódkérést, és ha egyet a fiók tesztelésére költ, olyan tartalék útvonalat szüntet meg, amelyre később szüksége lehet.

A kód a bejelentkező oldalt sem teszi megbízhatóvá: egy hasonló domainen megjelenő OTP-kérés begyűjt egy érvényes kódot, és az ablakon belül újrajátssza, a tanúsítvány pedig továbbra is megmondja, hova ír.

Ha a sorrend olyan profilhoz ér, amely nem tud válaszolni a kihívásra, javítsa ki a profilt, és tesztelje újra egy friss kóddal. Ha nem illeszkedő regisztrációs paraméterekhez ér, kérje meg az üzemeltetőt, hogy olvassa fel a tokenrekordot, mielőtt bárki bármit beszkennel. Ha zároláshoz ér, várja ki, ahelyett hogy klienst váltana — a fiók állapota az akadály, nem az alkalmazás.