Kata laluan VPN anda hanya seprivasi pengesahnya

Teliti empat soalan tentang mana-mana log masuk VPN: apa yang melindungi kata laluan semasa transit, komponen mana yang menerimanya, apa yang komponen itu lakukan dengannya, dan apa yang disimpan selepas itu. Setiap jawapan ialah kawalan yang berbeza, dan jawapan kukuh bagi satu tidak memberitahu apa-apa tentang yang lain. Kesilapannya ialah menganggap penyulitan terowong meliputi keempat-empatnya. Ia meliputi yang pertama, dan hanya yang pertama.

Tanya siapa yang menamatkan sesi, bukan sama ada sesi disulitkan.

Disulitkan untuk siapa, sebenarnya?

TLS melindungi kata laluan antara klien dan apa sahaja yang menamatkan sambungan. Jika titik hujung itu ialah get laluan VPN, kod pengesahan get laluan melihat kata laluan dalam teks biasa, mengesahkannya, dan menyalurkannya atau nilai terbitan ke hadapan. Itu reka bentuk yang dimaksudkan, bukan kebocoran. Pemerhati rangkaian di laluan tidak mempelajari apa-apa yang berguna, dan komponen yang melakukan pengesahan mempelajari semua yang diperlukannya.

Komuniti OpenVPN mendokumentasikan ini secara eksplisit: auth-user-pass-verify menyerahkan kelayakan yang dikemukakan kepada skrip atau pemalam pengesahan. Ia ialah penyerahan yang disengajakan antara komponen, dan ia tergolong dalam model kepercayaan sebagai pihak yang dinamakan.

Pengesah melihat kata laluan

Sebaik sahaja komponen menerima kata laluan untuk mengesahkannya, kawalan akses, pengelogan dan kualiti kodnya menentukan sama ada rahsia itu kekal terkurung. Skrip yang menulis kelayakan ke dalam log, atau pemalam yang menyimpannya dalam cache, mencipta pendedahan yang jauh lebih besar daripada protokol. Akses bergantung pada seni bina dan peranan, bukan terowong, sebab itulah pemilik perkhidmatan yang mengawal pengesah tergolong dalam penilaian.

Kaedah berbeza mendedahkan bahan berbeza. Pengesahan sijil membuktikan kunci peribadi tanpa menghantarnya, dan aliran persekutuan boleh menyimpan kata laluan pada pembekal identiti sambil mengeluarkan penegasan terhad kepada VPN. Reka bentuk itu menyempitkan bulatan; tiada satu pun menghapuskan setiap pihak yang dipercayai.

Cincangan yang disimpan melindungi peringkat yang berbeza

Panduan NIST memisahkan penghantaran terlindung daripada penyimpanan pengesah yang tahan. Pengasinan dan skema cincangan berkos mengatasi ancaman pengesah tersimpan, iaitu apa yang berlaku selepas itu jika pangkalan data bocor. Ia tidak melakukan apa-apa untuk komponen masa jalan yang mesti menerima input untuk membandingkannya. Membaca panduan seolah-olah ia menjanjikan kerahsiaan masa jalan ialah kesilapan kategori.

Oleh itu, stor kata laluan yang dicincang dengan baik dan skrip pengesahan yang terdedah boleh wujud bersama dalam satu produk tanpa percanggahan.

Memilih kaedah yang menyempitkan bulatan

Jika keperluannya ialah get laluan tidak pernah menerima kata laluan yang boleh diguna semula, pilih kaedah yang benar-benar menjaminnya; menukar sifer data tidak mencipta sifat itu. Mengesahkan sijil pelayan VPN memberitahu anda pasangan mana yang anda capai; ia tidak memberitahu apa-apa tentang cara pasangan itu mengendalikan kelayakan selepas itu. Kekalkan pengesahan pelayan, gunakan kelayakan berbeza bagi setiap perkhidmatan, dan ikuti aliran identiti yang disokong organisasi.

Rekodkan pihak yang menerima kata laluan, pihak yang mengesahkannya dan bentuk ia disimpan. Ketiga-tiga jawapan itu terletak di sebelah profil sambungan, kerana ia hidup lebih lama daripada mana-mana terowong tertentu.

Soalan yang berguna bukanlah sama ada kata laluan disulitkan, tetapi daripada siapa ia disembunyikan, komponen mana yang menerimanya dan bentuk apa yang kekal selepas itu.