Metod EAP dahulu: hash kata laluan mana yang boleh digunakan VPN
VPN mengesahkan rahsia, bukan hash web. Baca kaedahnya, kemudian semak apa yang disimpan oleh stor sebelum berjanji kata laluan yang sama akan terus berfungsi.
Banyak pasukan mempunyai log masuk web yang berfungsi dan VPN yang menolak setiap kata laluan daripada jadual yang sama. Aplikasi web membandingkan hash yang dikiranya sendiri, manakala terowong meminta klien membuktikan pemilikan rahsia dengan cara yang mesti dapat diperiksa oleh pelayan. Ini keperluan berbeza terhadap bahan yang disimpan. Di celah antara keduanya terhenti sebahagian besar projek sebegini.
Baca kaedahnya, kemudian skemanya
Catat bukti apa yang diperlukan oleh kaedah yang dipilih sebelum melihat mana-mana skema. Kaedah cabaran-tindak balas memerlukan bahan yang daripadanya pelayan boleh mengira tindak balas jangkaan, yang dalam praktiknya bermakna kata laluan atau bentuk terbitan yang serasi. Kaedah yang membawa kata laluan di dalam terowong terlindung memerlukan kata laluan itu sendiri di pengesah. Baca dokumentasi kaedah untuk keperluan pengesah, bukan untuk konfigurasi klien, kerana keperluan klien biasanya bahagian yang mudah.
Hash bergaram yang dihasilkan oleh rangka kerja web moden tidak menyediakan kedua-duanya. Ia mengesahkan satu perbandingan tertentu dan tidak boleh dikembalikan kepada rahsia asalnya.
Cabaran-tindak balas tidak boleh menggunakan hash bergaram
MSCHAPv2 ialah pertukaran cabaran-tindak balas, jadi pelayan tidak pernah menerima kata laluan dan tidak boleh membandingkan rentetan yang disimpan. Ia mesti menerbitkan tindak balas jangkaan daripada bahan yang sudah dimilikinya, dan itulah sebabnya bentuk simpanan yang serasi begitu sempit. Nilai bcrypt atau Argon2 dengan garam setiap pengguna adalah sehala dengan cara yang menyingkirkan pertukaran itu sepenuhnya. Jadual di bawah bermula daripada bentuk simpanan dan bukan nama kaedah, kerana bentuk simpanan yang menentukan jawapannya.
| 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 pemalam SQL untuk strongSwan mentakrifkan skemanya sendiri untuk konfigurasi dan kelayakan, dan projek itu masih menandakan pemalam tersebut sebagai eksperimen. Tiada apa-apa di dalamnya menyesuaikan diri dengan jadual pengguna sesuatu aplikasi atau meneka skema pencincangan mana yang menghasilkan nilai yang disimpan. Jadi pilihan realistik ialah penghijrahan ke stor yang boleh digunakan oleh get laluan, atau perkhidmatan pengesahan di hadapan stor sedia ada yang boleh melakukan pertukaran itu. Apa-apa lagi ialah penyambung dengan andaian tersembunyi di dalamnya.
RADIUS memindahkan kerja, bukan keperluan
Mewakilkan EAP kepada pelayan RADIUS mengubah tempat pengesahan berlaku dan biasanya menambah baik jejak audit. Ia tidak memulihkan kata laluan daripada hash sehala, jadi perkhidmatan pengesahan masih memerlukan bahan yang serasi dengan kaedah yang ditamatkannya. Pasukan mengetahui perkara ini selepas membina laluan RADIUS dan menemui dinding yang sama di hujung yang lain.
Di tempat pelayan RADIUS boleh membaca direktori yang menyimpan kelayakan serasi, reka bentuk itu berfungsi dan get laluan VPN kekal mudah. Di tempat ia tidak boleh, jawapan jujurnya ialah perubahan pendaftaran dan bukan penyambung lain. Peruntukan dan pembatalan milik sesiapa yang memiliki identiti, jadi jadual yang disalin tanpa proses penyegerakan yang disokong ialah kitaran hayat kelayakan kedua dan bukan log masuk tunggal. Ia mula terpesong kali pertama seseorang menetapkan semula kata laluan di satu tempat sahaja, dan pesongan itu senyap sehingga akaun yang wujud dalam kedua-dua sistem berkelakuan berbeza dalam setiap satu.
Hadkan akaun yang membaca direktori itu kepada bacaan tersebut sahaja, dan asingkannya daripada akaun yang digunakan oleh get laluan untuk konfigurasinya sendiri. Akaun pentadbir yang dikongsi menjadikan reka bentuk baca sahaja kepada jejari kesan yang jauh lebih luas.
Di mana akaun itu patut tinggal
Setelah persoalan bahan diselesaikan, tinggal dua seni bina. Get laluan boleh memiliki stor kelayakan kecil yang hanya dibacanya, atau mewakilkan kepada perkhidmatan pengesahan yang berdiri di hadapan direktori korporat.
Yang pertama lebih mudah difikirkan dan lebih buruk bagi pengguna, yang akhirnya mempunyai kata laluan kedua untuk diselenggara. Yang kedua mengekalkan satu identiti dan menambah kebergantungan pada perkhidmatan yang kini mesti hidup sebelum sesiapa boleh menyambung. Kedua-duanya tidak salah, tetapi pilihan itu patut dicatat di sebelah konfigurasi get laluan, kerana jika tidak jurutera seterusnya akan menganggap yang satu lagi dipilih. Apa pun pilihan anda, dua arahan di bawah ialah yang menunjukkan keadaan semasa sebelum anda mengubahnya.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsPengesahan akaun juga tidak menyelesaikan kebenaran. Keahlian kumpulan, keadaan peranti dan kebenaran rangkaian masih memerlukan pemetaan eksplisit selepas pengguna membuktikan identiti yang diperlukan. Sambungan yang disahkan dengan sempurna dan tidak membenarkan apa-apa ialah hasil dasar, bukan pepijat dalam kaedah.