Mengapa kode sekali pakai yang valid tetap gagal saat masuk VPN

Anda membuka klien VPN, mengetik kata sandi, dan enam digit dari autentikator Anda kembali sebagai tidak valid — dua kali, lalu ketiga kalinya. Tidak ada yang berubah pada akun sejak kemarin, jadi naluri pertama adalah menghapus entri di autentikator dan memindainya lagi — biasanya ini perbaikan yang salah. Kode sekali pakai bukan kata sandi kedua: gateway harus memintanya pada langkah tertentu, dari entri terdaftar tertentu, di dalam jendela tertentu, dan sebagian besar penolakan terjadi sebelum digit dibandingkan. Tentukan di langkah mana Anda berada sebelum menyentuh pendaftaran.

Urutan permintaan menunjukkan alur mana yang Anda jalani

Tiga bentuk mencakup hampir setiap proses masuk VPN yang melibatkan kode. Pada bentuk dua langkah, klien mengirim kata sandi, server menerbitkan tantangan, dan klien bertanya lagi. Pada bentuk gabungan, gateway menginginkan kata sandi dan kode dalam satu pengiriman — kadang digabung, kadang setelah pemisah yang hanya didokumentasikan operator. Pada bentuk peramban, klien tidak punya kolom sama sekali: kode dimasukkan ke halaman web, atau persetujuan push menggantikannya, dan klien desktop menunggu hasilnya.

Salah bentuk terlihat seperti kode buruk. Tempelkan kode baru ke kolom khusus kata sandi, dan server akan membacanya sebagai bagian dari kata sandi. Di sisi klien, OpenVPN 2.4 dan yang lebih baru membuat perbedaannya terlihat: server yang menjawab dengan AUTH_FAILED,CRV1: mengharapkan respons tantangan, sehingga profil memerlukan static-challenge atau berkas kata sandi dalam bentuk SCRV1:. Profil lama yang hanya membawa auth-user-pass memvalidasi kata sandi lalu berhenti, yang di log tampak seperti kegagalan OTP padahal tidak ada kode yang dikirim.

WireGuard layak disebut sebagai pengecualian: ia mengautentikasi pasangan kunci, bukan orang, jadi tidak ada kolom untuk kode. Jika penyedia mengiklankan satu, sesuatu di luar terowongan yang menerimanya.

Apa yang dilakukan server dengan enam digit itu

Kode berbasis waktu mengikuti RFC 6238, yang membungkus konstruksi berbasis penghitung yang lebih tua dari RFC 4226: HMAC atas faktor bergerak, secara bawaan dipotong menjadi enam digit. Untuk TOTP faktor bergeraknya adalah waktu Unix saat ini dibagi satu langkah, 30 detik kecuali operator mengubahnya. Verifikator tidak pernah membandingkan digit Anda dengan nilai tersimpan; ia menghitung ulang kode yang diharapkan dari benih bersama dan biasanya menerima langkah tetangga juga, sehingga perjalanan pulang-pergi yang lambat tidak menggagalkan proses masuk.

Dua konsekuensi terlewat. Zona waktu ponsel tidak relevan, karena benih tidak pernah melihat jam lokal — hanya simpangan dari UTC sebenarnya yang penting, dan perangkat yang berjalan dua menit lebih cepat gagal di setiap kode sambil menampilkan hitungan mundur yang bersih. Dan kode bersifat sekali pakai secara desain: verifikator mengingat nilai penghitung terakhir yang diterimanya untuk benih itu, sehingga digit yang sama yang dikirim ulang ditolak bahkan di dalam jendela yang sama. Klien yang mencoba lagi setelah waktu habis dapat membakar kode yang baru saja dikirimnya.

Token berbasis penghitung memajukan penghitungnya pada setiap tekanan, sehingga keluar dari sinkronisasi setelah kode dibuat tetapi tidak pernah dikirim; perbaikan yang biasa adalah jendela penyelarasan ulang yang menerima beberapa nilai ke depan. Jika operator mendaftarkan HOTP sedangkan aplikasi Anda menampilkan TOTP, setiap nilai salah dengan cara yang tampak seperti masalah jam. URI penyediaan di balik kode QR menyebutkan jenis, digit, periode, dan hash.

Kegagalan yang tampak seperti kode salah

Entri terdaftar adalah penyebab paling umum. Aplikasi autentikator memberi label entri menurut penerbit dan akun, sehingga siapa pun yang memiliki dua identitas pada VPN yang sama bisa berakhir dengan dua entri yang labelnya berbeda satu karakter. Kode berlaku untuk benih yang menghasilkannya dan tidak untuk apa pun yang lain. Bandingkan label di ponsel dengan nama pengguna yang dicatat server, bukan dengan yang Anda ingat telah diketik.

Kedua, kumpulan parameter yang tidak cocok. Benih yang didaftarkan dengan delapan digit, periode 60 detik, atau SHA-256 menghasilkan kode yang ditolak verifikator yang mengharapkan enam digit, 30 detik, dan SHA-1, dan di sisi klien itu tidak bisa dibedakan dari kode yang salah. Ini muncul setelah migrasi ketika entri ditambahkan ulang dari foto kode QR, atau ketika catatan token dibangun ulang dengan nilai bawaan.

Ketiga, ini bukan soal kodenya. Gateway biasanya mengembalikan satu kegagalan autentikasi generik untuk kata sandi salah, kode kedaluwarsa, dan akun dinonaktifkan, dengan sengaja, agar tidak ada yang bisa menyelidiki faktor mana yang gagal. Baca log gateway atau RADIUS alih-alih banner klien: tantangan yang tidak pernah diterbitkan, penolakan akses tanpa atribut OTP, dan penolakan kebijakan semuanya tampak sama di layar dan mengarah ke langkah berikutnya yang berbeda.

Urutan singkat yang mempersempitnya

Mulai dari pemeriksaan termurah dan berhenti pada langkah pertama yang tidak terpenuhi.

1. Tunggu kode baru, kirim sekali, dan catat apakah tantangan muncul sebelum atau setelah kata sandi diterima.
2. Cocokkan label di autentikator dengan nama pengguna yang disimpan server.
3. Pastikan profil sama sekali dapat menjawab tantangan, seperti pada kasus CRV1 di atas.
4. Bandingkan jam perangkat dengan sumber waktu yang dikenal; simpangan lebih dari beberapa puluh detik merusak TOTP dengan sendirinya.
5. Tanyakan kepada operator apakah token itu TOTP atau HOTP, dan digit, periode, serta hash mana yang didaftarkan.

Dua aturan mencegah hal ini memperburuk keadaan. Jangan mencoba berulang kali: banyak gateway menghitung kegagalan per akun dan entah menguncinya atau mulai menunda respons, sehingga satu ledakan mengubah kesalahan konfigurasi kecil menjadi tiket dukungan. Dan jangan mendaftarkan ulang token sebagai diagnosa, karena itu membatalkan benih lama; jika kesalahan sebenarnya adalah tantangan yang tidak pernah dikirim klien, sekarang Anda punya dua perubahan untuk dijelaskan, bukan satu.

Jauhkan benih dan kode pemulihan dari lingkaran

Enam digit dan rahasia di baliknya tidak dapat saling menggantikan. Kode QR penyediaan atau benih Base32 menghasilkan setiap kode masa depan untuk akun, jadi ia termasuk kategori yang sama dengan kata sandi: bukan di tangkapan layar, bukan di komentar tiket, bukan di obrolan dengan orang yang menghubungi Anda lebih dulu. Kode pemulihan adalah mekanisme terpisah — sekali pakai, sering melewati permintaan kode sepenuhnya, dan menghabiskan satu untuk menguji akun menghapus jalur cadangan yang mungkin Anda butuhkan nanti.

Kode juga tidak membuat halaman masuk tepercaya: permintaan OTP di domain serupa mengumpulkan kode yang valid dan memutarnya kembali di dalam jendela, dan sertifikat tetap yang memberi tahu Anda di mana Anda mengetik.

Jika urutan berakhir pada profil yang tidak dapat menjawab tantangan, perbaiki profil dan uji ulang dengan satu kode baru. Jika berakhir pada parameter pendaftaran yang tidak cocok, minta operator membaca catatan token sebelum siapa pun memindai apa pun. Jika berakhir pada penguncian, tunggu sampai selesai alih-alih mengganti klien — keadaan akun adalah penghalangnya, bukan aplikasinya.