Kata sandi VPN Anda hanya seprivat verifikatornya

Telusuri empat pertanyaan tentang setiap login VPN: apa yang melindungi kata sandi saat transit, komponen mana yang menerimanya, apa yang dilakukan komponen itu dengannya, dan apa yang disimpan setelahnya. Setiap jawaban adalah kontrol yang berbeda, dan jawaban kuat untuk satu tidak menjelaskan apa pun tentang yang lain. Kesalahannya adalah memperlakukan enkripsi terowongan seolah-olah mencakup keempatnya. Enkripsi itu mencakup yang pertama, dan hanya yang pertama.

Tanyakan siapa yang mengakhiri sesi, bukan apakah sesi terenkripsi.

Terenkripsi untuk siapa, tepatnya?

TLS melindungi kata sandi antara klien dan apa pun yang mengakhiri koneksi. Jika titik akhir itu adalah gateway VPN, kode autentikasi gateway melihat kata sandi dalam teks biasa, memvalidasinya, dan meneruskannya atau meneruskan nilai turunannya. Itu desain yang dimaksudkan, bukan kebocoran. Pengamat jaringan di jalur tidak mempelajari apa pun yang berguna, dan komponen yang melakukan verifikasi mempelajari semua yang dibutuhkannya.

Komunitas OpenVPN mendokumentasikannya secara eksplisit: auth-user-pass-verify menyerahkan kredensial yang diajukan ke skrip atau plugin verifikasi. Itu adalah penyerahan yang disengaja antarkomponen, dan itu termasuk dalam model kepercayaan sebagai pihak yang disebutkan.

Verifikator melihat kata sandi

Setelah sebuah komponen menerima kata sandi untuk memverifikasinya, kontrol akses, pencatatan, dan kualitas kodenya menentukan apakah rahasia itu tetap terkungkung. Skrip yang menulis kredensial ke log, atau plugin yang menyimpannya di cache, menciptakan paparan yang jauh lebih besar daripada yang dilakukan protokol. Akses bergantung pada arsitektur dan peran, bukan pada terowongan, karena itu pemilik layanan yang mengendalikan verifikator termasuk dalam penilaian.

Metode berbeda memaparkan materi berbeda. Autentikasi sertifikat membuktikan kunci privat tanpa mengirimkannya, dan alur federasi dapat menyimpan kata sandi di penyedia identitas sambil menerbitkan pernyataan terbatas ke VPN. Desain itu mempersempit lingkaran; tidak satu pun menghilangkan setiap pihak tepercaya.

Hash yang tersimpan melindungi tahap yang berbeda

Panduan NIST memisahkan transmisi terlindungi dari penyimpanan verifikator yang tahan lama. Pengasinan dan skema hashing berbiaya menangani ancaman verifikator tersimpan, yaitu apa yang terjadi setelah kejadian jika basis data bocor. Keduanya tidak melakukan apa pun untuk komponen runtime yang harus menerima masukan untuk membandingkannya. Membaca panduan seolah-olah menjanjikan kerahasiaan runtime adalah kesalahan kategori.

Penyimpanan kata sandi yang di-hash dengan baik dan skrip verifikasi yang terekspos karena itu dapat hidup berdampingan dalam satu produk tanpa kontradiksi.

Memilih metode yang mempersempit lingkaran

Jika persyaratannya adalah gateway tidak pernah menerima kata sandi yang dapat digunakan ulang, pilih metode yang benar-benar menjaminnya; mengganti sandi data tidak menciptakan sifat itu. Memverifikasi sertifikat server VPN memberi tahu Anda pasangan mana yang Anda capai; itu tidak menjelaskan bagaimana pasangan itu menangani kredensial setelahnya. Pertahankan verifikasi server, gunakan kredensial berbeda per layanan, dan ikuti alur identitas yang didukung organisasi.

Catat pihak yang menerima kata sandi, pihak yang memvalidasinya, dan bentuk penyimpanannya. Ketiga jawaban itu berada di samping profil koneksi, karena umurnya lebih panjang daripada terowongan tertentu mana pun.

Pertanyaan yang berguna bukanlah apakah kata sandi terenkripsi, melainkan dari siapa kata sandi itu disembunyikan, komponen mana yang menerimanya, dan bentuk apa yang bertahan setelahnya.