Ke mana kod cabaran statik pergi semasa log masuk OpenVPN

Klien menunjukkan kotak kedua selepas medan kata laluan, anda menaip kod daripada token perkakasan, dan log masuk masih gagal dengan ralat pengesahan. Kotak itu wujud, jadi profil memintanya. Sama ada pelayan pernah menerima nilai itu dalam bentuk yang difahaminya ialah persoalan lain, dan itulah yang wajar dijawab dahulu.

Mulakan dengan gesaan yang klien anda benar-benar tunjukkan

Profil boleh membawa arahan cabaran statik dengan rentetan gesaan dan bendera yang mengawal sama ada respons dipaparkan semasa anda menaip. Gesaan ialah apa yang anda lihat dalam dialog; bendera ialah keutamaan paparan untuk input yang sama itu. Kedua-duanya tidak memberitahu pelayan cara mengesahkan apa-apa.

Kira medan yang benar-benar diberikan kepada anda. Satu medan untuk nama pengguna ditambah satu medan bertopeng ialah log masuk kata laluan biasa tanpa sebarang cabaran. Medan kedua yang muncul selepas kata laluan, dengan labelnya sendiri, ialah klien yang melaksanakan interaksi cabaran.

Jika kotak kedua tidak pernah muncul dalam klien yang anda gunakan, klien itu mungkin tidak melaksanakan interaksi tersebut, atau melaksanakannya hanya melalui antara muka lain seperti antara muka pengurusan. Memeriksa klien lebih murah daripada menulis semula profil, dan biasanya di situlah ketidakpadanan sebenarnya berada.

Apa yang pelayan mesti sudah sokong

Profil menerangkan apa yang klien patut kumpulkan. Ia tidak mengaktifkan pengesahan pada pelayan, dan pelayan tanpa integrasi pengesahan yang sepadan hanya akan menerima kata laluan yang tidak dikenalnya. Itulah sebabnya sesetengah penggunaan menunjukkan gesaan dan menolak setiap kod, dan itulah sebabnya jawapan pengendali tentang mekanisme mana yang melakukan pemeriksaan ialah jawapan yang penting.

Tanya pengendali mekanisme mana yang melakukan pemeriksaan. Ia mungkin pemalam yang bercakap dengan PAM, cangkuk skrip yang mengesahkan respons terhadap perkhidmatan token, atau integrasi berasaskan pengurusan yang menghuraikan sendiri nilai yang dikemas. Setiap satunya menjangkakan input yang sedikit berbeza.

Di sinilah jangkaan juga perlu ditentukur. Gesaan kedua ialah mekanisme input, bukan bukti bahawa faktor kedua dikuatkuasakan, kerana penguatkuasaan berlaku di pihak pelayan dan hanya kelihatan apabila anda menguji kod yang salah.

Medan berkod yang dihantar oleh antara muka pengurusan

Apabila antara muka hadapan memandu sambungan melalui antara muka pengurusan, kata laluan dan respons cabaran dikemas menjadi satu nilai sebelum dihantar. Rujukan antara muka pengurusan mendokumenkan formatnya: awalan, kemudian kata laluan dan respons sebagai komponen Base64 yang berasingan.

Base64 ialah pengekodan, bukan perlindungan. Ia tidak menyembunyikan apa-apa daripada sesiapa yang boleh membaca medan itu, dan ia tidak menukar kod sekali guna menjadi sesuatu yang boleh diguna semula. Nilai yang dikemas wajar mendapat layanan yang sama seperti kata laluan: keluar daripada profil dikongsi, keluar daripada baris arahan dan keluar daripada log diagnostik.

Pengekodan itu juga merupakan sumber kekeliruan yang paling biasa, kerana kini ada tiga bentuk yang kelihatan serupa dan tidak boleh ditukar ganti. Fail kelayakan biasa menyimpan kata laluan. Gabungan literal kata laluan dan kod menyimpan rentetan yang berbeza. Respons berkemas klien pengurusan menyimpan yang ketiga. Sahkan yang mana laluan pengesahan anda jangkakan sebelum menukar medan hanya kerana ralat telah hilang.

Statik berbanding dinamik: masa yang berbeza

Cabaran statik diketahui sebelum kelayakan pertama dihantar, jadi klien boleh memintanya lebih awal. Cabaran dinamik datang kemudian, dihantar oleh aliran pengesahan selepas pertukaran sudah bermula, dan ia memerlukan klien yang mampu mengendalikan permintaan di tengah-tengah perbualan.

Sokongan untuk satu tidak memberikan yang lain. Arahan profil yang mengkonfigurasi gesaan statik tidak melaksanakan cabaran yang dimulakan pelayan, dan antara muka hadapan yang mengendalikan permintaan dinamik mungkin masih tidak memaparkan yang statik. Membaca pihak mana yang memulakan permintaan ialah cara terpantas untuk membezakannya.

Operasi tanpa pengawasan ialah titik apabila ini menjadi persoalan reka bentuk dan bukan persoalan antara muka. Kod yang disimpan bukan kelayakan masa but yang tahan lama, dan sambungan semula berjam-jam kemudian akan memerlukan input baharu melainkan penggunaan menyokong susunan token yang pengendali telah aktifkan secara sengaja.

Uji kejayaan dan kegagalan, bukan hanya dialog

Jalankan kedua-dua separuh ujian. Kelayakan betul dengan respons yang sah sepatutnya berjaya; kelayakan betul dengan respons yang sengaja salah sepatutnya ditolak. Jika kedua-duanya berjaya, klien mengumpulkan input yang tidak disahkan oleh apa-apa, dan dialog telah disalah anggap sebagai kawalan. Ujian tunggal itu menangkap lebih banyak penggunaan daripada sebarang semakan profil.

Kemudian ulangi sambungan selepas sambungan semula, dengan akaun yang tidak didaftarkan, dan melalui klien yang pengguna anda benar-benar jalankan. Gesaan muncul ialah tingkah laku klien; kod yang salah ditolak ialah pelayan yang menguatkuasakan sesuatu.