Ke mana kode tantangan statis pergi saat masuk ke OpenVPN

Klien menampilkan kotak kedua setelah kolom kata sandi, Anda mengetik kode dari token perangkat keras, dan proses masuk tetap gagal dengan kesalahan autentikasi. Kotak itu ada, jadi profil memintanya. Apakah server pernah menerima nilai itu dalam bentuk yang ia pahami adalah pertanyaan lain, dan itulah yang layak dijawab lebih dulu.

Mulailah dari prompt yang benar-benar ditampilkan klien Anda

Sebuah profil dapat membawa direktif tantangan statis dengan string prompt dan flag yang mengatur apakah respons ditampilkan saat Anda mengetik. Prompt adalah yang Anda lihat di dialog; flag adalah preferensi tampilan untuk input yang sama itu. Keduanya tidak memberi tahu server cara memverifikasi apa pun.

Hitung kolom yang benar-benar Anda terima. Satu kolom untuk nama pengguna ditambah satu kolom bertopeng adalah proses masuk kata sandi biasa tanpa tantangan apa pun. Kolom kedua yang muncul setelah kata sandi, dengan labelnya sendiri, adalah klien yang menerapkan interaksi tantangan.

Jika kotak kedua tidak pernah muncul di klien yang Anda pakai, klien itu mungkin tidak menerapkan interaksi tersebut, atau hanya menerapkannya melalui antarmuka lain seperti antarmuka manajemen. Memeriksa klien lebih murah daripada menulis ulang profil, dan biasanya di situlah ketidakcocokan sebenarnya berada.

Apa yang harus sudah didukung server

Profil menjelaskan apa yang harus dikumpulkan klien. Profil tidak mengaktifkan verifikasi di server, dan server tanpa integrasi autentikasi yang sesuai hanya akan menerima kata sandi yang tidak dikenalnya. Itulah sebabnya sebagian penerapan menampilkan prompt dan menolak setiap kode, dan itulah sebabnya jawaban operator tentang mekanisme mana yang melakukan pemeriksaan adalah jawaban yang penting.

Tanyakan kepada operator mekanisme mana yang melakukan pemeriksaan. Bisa jadi plugin yang berbicara dengan PAM, hook skrip yang memvalidasi respons terhadap layanan token, atau integrasi berbasis manajemen yang mengurai sendiri nilai yang dikemas. Masing-masing mengharapkan input yang sedikit berbeda.

Di sinilah ekspektasi juga perlu dikalibrasi. Prompt kedua adalah mekanisme input, bukan bukti bahwa faktor kedua ditegakkan, karena penegakan terjadi di sisi server dan hanya terlihat saat Anda menguji kode yang salah.

Kolom berkode yang dikirim antarmuka manajemen

Saat antarmuka depan menjalankan koneksi melalui antarmuka manajemen, kata sandi dan respons tantangan dikemas menjadi satu nilai sebelum dikirim. Referensi antarmuka manajemen mendokumentasikan formatnya: sebuah awalan, lalu kata sandi dan respons sebagai komponen Base64 terpisah.

Base64 adalah pengodean, bukan perlindungan. Ia tidak menyembunyikan apa pun dari siapa pun yang dapat membaca kolom itu, dan tidak mengubah kode sekali pakai menjadi sesuatu yang dapat dipakai ulang. Nilai yang dikemas layak mendapat perlakuan yang sama dengan kata sandi: keluar dari profil bersama, keluar dari baris perintah, dan keluar dari log diagnostik.

Pengodean itu juga merupakan sumber kebingungan paling umum, karena sekarang ada tiga bentuk yang terlihat mirip dan tidak dapat dipertukarkan. Berkas kredensial biasa berisi kata sandi. Penggabungan harfiah kata sandi dan kode berisi string lain. Respons terkemas dari klien manajemen berisi bentuk ketiga. Pastikan mana yang diharapkan jalur verifikasi Anda sebelum mengubah kolom hanya karena sebuah kesalahan hilang.

Statis versus dinamis: waktu yang berbeda

Tantangan statis diketahui sebelum kredensial pertama dikirim, sehingga klien dapat memintanya lebih awal. Tantangan dinamis datang kemudian, dikirim oleh alur autentikasi setelah pertukaran sudah dimulai, dan membutuhkan klien yang mampu menangani permintaan di tengah percakapan.

Dukungan untuk salah satunya tidak memberi Anda yang lain. Direktif profil yang mengatur prompt statis tidak menerapkan tantangan yang diprakarsai server, dan antarmuka depan yang menangani permintaan dinamis mungkin masih tidak menampilkan yang statis. Membaca pihak mana yang memulai permintaan adalah cara tercepat untuk membedakannya.

Operasi tanpa pengawasan adalah titik ketika ini menjadi pertanyaan desain, bukan pertanyaan antarmuka. Kode yang disimpan bukan kredensial waktu boot yang tahan lama, dan menyambung ulang berjam-jam kemudian akan memerlukan input baru kecuali penerapan mendukung pengaturan token yang sengaja diaktifkan operator.

Uji keberhasilan dan kegagalan, bukan hanya dialognya

Jalankan kedua bagian pengujian. Kredensial yang benar dengan respons yang valid seharusnya berhasil; kredensial yang benar dengan respons yang sengaja salah seharusnya ditolak. Jika keduanya berhasil, klien mengumpulkan input yang tidak diverifikasi apa pun, dan dialog telah disalahartikan sebagai kontrol. Satu pengujian itu menangkap lebih banyak penerapan daripada sebanyak apa pun tinjauan profil.

Lalu ulangi koneksi setelah menyambung ulang, dengan akun yang tidak terdaftar, dan melalui klien apa pun yang benar-benar dijalankan pengguna Anda. Munculnya prompt adalah perilaku klien; ditolaknya kode yang salah adalah server yang menegakkan sesuatu.