Mengapa kod sekali guna yang sah masih gagal semasa log masuk VPN

Anda membuka klien VPN, menaip kata laluan, dan enam digit daripada pengesah anda kembali sebagai tidak sah — dua kali, kemudian kali ketiga. Tiada apa yang berubah pada akaun sejak semalam, jadi naluri pertama ialah memadam entri dalam pengesah dan mengimbasnya semula — biasanya itulah pembaikan yang salah. Kod sekali guna bukan kata laluan kedua: get laluan mesti memintanya pada langkah tertentu, daripada entri berdaftar tertentu, dalam tetingkap tertentu, dan kebanyakan penolakan berlaku sebelum digit dibandingkan. Tentukan langkah mana anda berada sebelum menyentuh pendaftaran.

Susunan gesaan memberitahu aliran mana anda berada

Tiga bentuk merangkumi hampir setiap log masuk VPN yang melibatkan kod. Dalam bentuk dua langkah, klien menghantar kata laluan, pelayan mengeluarkan cabaran, dan klien bertanya lagi. Dalam bentuk gabungan, get laluan mahukan kata laluan dan kod dalam satu penyerahan — kadangkala digabungkan, kadangkala selepas pemisah yang hanya didokumenkan oleh pengendali. Dalam bentuk pelayar, klien tidak mempunyai medan sama sekali: kod dimasukkan ke halaman web, atau kelulusan tolak menggantikannya, dan klien desktop menunggu hasilnya.

Bentuk yang salah kelihatan seperti kod buruk. Tampal kod baharu ke dalam medan khusus kata laluan, dan pelayan akan membacanya sebagai bahagian kata laluan. Di sebelah klien, OpenVPN 2.4 dan lebih baharu menjadikan perbezaannya kelihatan: pelayan yang menjawab dengan AUTH_FAILED,CRV1: menjangka respons cabaran, jadi profil memerlukan static-challenge atau fail kata laluan dalam bentuk SCRV1:. Profil lama yang hanya membawa auth-user-pass mengesahkan kata laluan dan kemudian berhenti, yang dalam log kelihatan seperti kegagalan OTP walaupun tiada kod dihantar.

WireGuard wajar disebut sebagai pengecualian: ia mengesahkan pasangan kunci, bukan orang, jadi tiada medan untuk kod. Jika pembekal mengiklankan satu, sesuatu di luar terowong yang menerimanya.

Apa yang pelayan lakukan dengan enam digit itu

Kod berasaskan masa mengikut RFC 6238, yang membungkus binaan berasaskan pembilang yang lebih lama daripada RFC 4226: HMAC atas faktor bergerak, dipotong kepada enam digit secara lalai. Untuk TOTP faktor bergerak ialah masa Unix semasa dibahagi dengan satu langkah, 30 saat melainkan pengendali telah menukarnya. Pengesah tidak pernah membandingkan digit anda dengan nilai tersimpan; ia mengira semula kod yang dijangka daripada benih berkongsi dan biasanya menerima langkah jiran juga, jadi perjalanan pergi balik yang perlahan tidak menggagalkan log masuk.

Dua akibat terlepas pandang. Zon waktu telefon tidak relevan, kerana benih tidak pernah melihat jam tempatan — hanya sisihan daripada UTC sebenar yang penting, dan peranti yang laju dua minit gagal pada setiap kod sambil memaparkan kiraan detik yang bersih. Dan kod adalah sekali guna mengikut reka bentuk: pengesah mengingati nilai pembilang terakhir yang diterimanya untuk benih itu, jadi digit yang sama dihantar semula ditolak walaupun dalam tetingkap yang sama. Klien yang mencuba semula selepas tamat masa boleh membakar kod yang baru dihantarnya.

Token berasaskan pembilang menggerakkan pembilangnya pada setiap tekanan, jadi ia tidak lagi segerak selepas kod dijana tetapi tidak pernah dihantar; pembaikan biasa ialah tetingkap penyegerakan semula yang menerima beberapa nilai ke hadapan. Jika pengendali mendaftar HOTP sedangkan aplikasi anda memaparkan TOTP, setiap nilai salah dengan cara yang kelihatan seperti masalah jam. URI penyediaan di sebalik kod QR menamakan jenis, digit, tempoh dan cincangan.

Kegagalan yang kelihatan seperti kod salah

Entri berdaftar ialah punca paling biasa. Aplikasi pengesah melabel entri mengikut pengeluar dan akaun, jadi sesiapa yang mempunyai dua identiti pada VPN yang sama boleh berakhir dengan dua entri yang labelnya berbeza satu aksara. Kod sah hanya untuk benih yang menjananya dan tidak untuk apa-apa lagi. Bandingkan label pada telefon dengan nama pengguna yang direkodkan pelayan, bukan dengan apa yang anda ingat telah ditaip.

Kedua, set parameter yang tidak sepadan. Benih yang didaftarkan dengan lapan digit, tempoh 60 saat atau SHA-256 menghasilkan kod yang ditolak oleh pengesah yang menjangka enam digit, 30 saat dan SHA-1, dan pada klien itu tidak dapat dibezakan daripada kod yang salah. Ia muncul selepas penghijrahan apabila entri ditambah semula daripada foto kod QR, atau apabila rekod token dibina semula dengan nilai lalai.

Ketiga, ini bukan tentang kodnya. Get laluan biasanya memulangkan satu kegagalan pengesahan umum untuk kata laluan salah, kod tamat tempoh dan akaun dilumpuhkan, dengan sengaja, supaya tiada siapa dapat menyiasat faktor mana yang gagal. Baca log get laluan atau RADIUS dan bukannya sepanduk klien: cabaran yang tidak pernah dikeluarkan, penolakan akses tanpa atribut OTP dan penolakan dasar semuanya kelihatan sama di skrin dan membawa kepada langkah seterusnya yang berbeza.

Urutan pendek yang menyempitkannya

Mulakan dengan pemeriksaan paling murah dan berhenti pada langkah pertama yang tidak bertahan.

1. Tunggu kod baharu, hantar sekali, dan catat sama ada cabaran muncul sebelum atau selepas kata laluan diterima.
2. Padankan label dalam pengesah dengan nama pengguna yang disimpan pelayan.
3. Sahkan profil boleh menjawab cabaran sama sekali, seperti dalam kes CRV1 di atas.
4. Bandingkan jam peranti dengan sumber masa yang diketahui; sisihan melebihi beberapa puluh saat merosakkan TOTP dengan sendirinya.
5. Tanya pengendali sama ada token itu TOTP atau HOTP, dan digit, tempoh serta cincangan mana yang didaftarkan.

Dua peraturan menghalang perkara ini daripada menjadi lebih buruk. Jangan cuba berulang kali: banyak get laluan mengira kegagalan bagi setiap akaun dan sama ada menguncinya atau mula melambatkan respons, jadi satu letusan mengubah salah konfigurasi kecil menjadi tiket sokongan. Dan jangan daftar semula token sebagai diagnosis, kerana itu membatalkan benih lama; jika kerosakan sebenar ialah cabaran yang tidak pernah dihantar oleh klien, kini anda mempunyai dua perubahan untuk dijelaskan dan bukannya satu.

Jauhkan benih dan kod pemulihan daripada kitaran

Enam digit dan rahsia di sebaliknya tidak boleh saling menggantikan. Kod QR penyediaan atau benih Base32 menjana setiap kod masa depan untuk akaun, jadi ia tergolong dalam kategori yang sama dengan kata laluan: bukan dalam tangkapan skrin, bukan dalam ulasan tiket, bukan dalam sembang dengan seseorang yang menghubungi anda dahulu. Kod pemulihan ialah mekanisme berasingan — sekali guna, selalunya melangkau permintaan kod sepenuhnya, dan menghabiskan satu untuk menguji akaun menghapuskan jalan sandaran yang mungkin anda perlukan kemudian.

Kod juga tidak menjadikan halaman log masuk boleh dipercayai: gesaan OTP pada domain yang serupa mengumpul kod yang sah dan memainkannya semula dalam tetingkap itu, dan sijil masih yang memberitahu anda di mana anda menaip.

Jika urutan berakhir pada profil yang tidak boleh menjawab cabaran, betulkan profil dan uji semula dengan satu kod baharu. Jika ia berakhir pada parameter pendaftaran yang tidak sepadan, minta pengendali membaca rekod token sebelum sesiapa mengimbas apa-apa. Jika ia berakhir pada kuncian, tunggu ia berlalu dan bukannya menukar klien — keadaan akaun ialah penghalangnya, bukan aplikasi.