Metode EAP lebih dulu: hash kata sandi mana yang bisa dipakai VPN
VPN memverifikasi rahasianya, bukan hash web. Baca metodenya, lalu periksa apa yang disimpan penyimpanan sebelum menjanjikan kata sandi yang sama akan terus berfungsi.
Banyak tim punya login web yang berfungsi dan VPN yang menolak setiap kata sandi dari tabel yang sama. Aplikasi web membandingkan hash yang dihitungnya sendiri, sedangkan terowongan meminta klien membuktikan kepemilikan sebuah rahasia dengan cara yang harus dapat diperiksa oleh server. Keduanya adalah tuntutan berbeda terhadap materi yang disimpan. Di celah antara keduanya-lah sebagian besar proyek seperti ini terhenti.
Baca metodenya, lalu skemanya
Tuliskan bukti apa yang dituntut metode terpilih sebelum melihat skema apa pun. Metode tantangan-jawaban membutuhkan materi yang darinya server dapat menghitung jawaban yang diharapkan, yang dalam praktik berarti kata sandi atau bentuk turunan yang kompatibel. Metode yang membawa kata sandi di dalam terowongan terlindung membutuhkan kata sandi itu sendiri di verifikator. Bacalah dokumentasi metode untuk tuntutan verifikator, bukan untuk konfigurasi klien, karena tuntutan klien biasanya bagian yang mudah.
Hash bergaram yang dihasilkan kerangka web modern tidak menyediakan keduanya. Ia memverifikasi satu perbandingan tertentu dan tidak dapat dikembalikan ke rahasia asalnya.
Tantangan-jawaban tidak dapat memakai hash bergaram
MSCHAPv2 adalah pertukaran tantangan-jawaban, sehingga server tidak pernah menerima kata sandi dan tidak dapat membandingkan untai yang tersimpan. Ia harus menurunkan jawaban yang diharapkan dari materi yang sudah dimilikinya, dan itulah sebabnya bentuk tersimpan yang kompatibel begitu sempit. Nilai bcrypt atau Argon2 dengan garam per pengguna bersifat satu arah dengan cara yang sepenuhnya menyingkirkan pertukaran itu. Tabel di bawah dimulai dari bentuk penyimpanan, bukan dari nama metode, karena bentuk penyimpananlah yang menentukan jawabannya.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Dokumentasi plugin SQL untuk strongSwan mendefinisikan skema sendiri untuk konfigurasi dan kredensial, dan proyek itu masih menandai plugin tersebut sebagai eksperimental. Tidak ada yang di dalamnya menyesuaikan diri dengan tabel pengguna suatu aplikasi atau menebak skema hash mana yang menghasilkan nilai tersimpan. Jadi pilihan realistisnya adalah migrasi ke penyimpanan yang dapat dipakai gateway, atau layanan autentikasi di depan penyimpanan yang ada yang dapat melakukan pertukaran itu. Segala hal lain adalah konektor dengan asumsi tersembunyi di dalamnya.
RADIUS memindahkan pekerjaannya, bukan tuntutannya
Mendelegasikan EAP ke server RADIUS mengubah di mana verifikasi terjadi dan biasanya memperbaiki jejak audit. Ia tidak memulihkan kata sandi dari hash satu arah, jadi layanan autentikasi tetap membutuhkan materi yang kompatibel dengan metode yang diakhirinya. Tim mengetahui hal ini setelah membangun jalur RADIUS dan menemui dinding yang sama di ujung lain.
Di tempat server RADIUS dapat membaca direktori yang memuat kredensial kompatibel, rancangannya berfungsi dan gateway VPN tetap sederhana. Di tempat ia tidak dapat, jawaban jujurnya adalah perubahan pendaftaran, bukan konektor lain. Penyediaan dan pencabutan menjadi milik siapa pun yang memiliki identitas, sehingga tabel yang disalin tanpa proses sinkronisasi yang didukung adalah siklus hidup kredensial kedua, bukan sekali masuk. Ia menyimpang pertama kali seseorang mengatur ulang kata sandi hanya di satu tempat, dan penyimpangan itu senyap sampai akun yang ada di kedua sistem berperilaku berbeda di masing-masing.
Batasi akun yang membaca direktori hanya pada pembacaan itu, dan pisahkan dari akun yang dipakai gateway untuk konfigurasinya sendiri. Akun administratif bersama mengubah rancangan hanya-baca menjadi radius dampak yang jauh lebih luas.
Di mana akun seharusnya berada
Setelah pertanyaan materi selesai, tersisa dua arsitektur. Gateway dapat memiliki penyimpanan kredensial kecil yang hanya dibacanya sendiri, atau mendelegasikan ke layanan autentikasi yang berada di depan direktori perusahaan.
Yang pertama lebih mudah dipikirkan dan lebih buruk bagi pengguna, yang akhirnya punya kata sandi kedua untuk dipelihara. Yang kedua mempertahankan satu identitas dan menambah ketergantungan pada layanan yang kini harus hidup sebelum siapa pun dapat terhubung. Keduanya tidak salah, tetapi pilihannya sebaiknya dicatat di samping konfigurasi gateway, karena kalau tidak, insinyur berikutnya akan menganggap yang lain yang dipilih. Apa pun pilihan Anda, dua perintah di bawah adalah yang menunjukkan keadaan saat ini sebelum Anda mengubahnya.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsAutentikasi akun juga tidak menyelesaikan otorisasi. Keanggotaan grup, keadaan perangkat, dan izin jaringan tetap memerlukan pemetaan eksplisit setelah pengguna membuktikan identitas yang diminta. Koneksi yang terautentikasi sempurna dan tidak mengotorisasi apa pun adalah hasil kebijakan, bukan kesalahan pada metodenya.