Una ang paraang EAP: aling hash ng password ang magagamit ng VPN
Biniberipika ng VPN ang sikreto, hindi ang web hash. Basahin ang paraan, pagkatapos tingnan kung ano ang hawak ng imbakan bago mangakong magpapatuloy ang parehong mga password.
Maraming koponan ang may web login na gumagana at VPN na tumatanggi sa bawat password mula sa parehong talahanayan. Inihahambing ng web application ang hash na siya mismo ang nagkalkula, samantalang hinihiling ng tunnel sa kliyente na patunayan ang paghawak ng isang sikreto sa paraang dapat masuri ng server. Magkaibang mga pangangailangan ang mga ito sa imbak na materyal. Nasa agwat sa pagitan ng dalawa ang karamihan ng ganitong proyekto ay natigil.
Basahin ang paraan, pagkatapos ang iskema
Isulat kung anong patunay ang hinihingi ng piniling paraan bago tumingin sa anumang iskema. Ang paraang hamon-tugon ay nangangailangan ng materyal na mapagkukunan ng server ng inaasahang tugon, na sa pagsasagawa ay nangangahulugang ang password o isang katugmang hinangong anyo. Ang paraang nagdadala ng password sa loob ng protektadong tunnel ay nangangailangan ng password mismo sa beripikador. Basahin ang dokumentasyon ng paraan para sa pangangailangan ng beripikador at hindi para sa konpigurasyon ng kliyente, dahil ang mga pangangailangan ng kliyente ay karaniwang ang madaling bahagi.
Ang hash na may asin na ginawa ng modernong web framework ay wala sa dalawa. Biniberipika nito ang isang partikular na paghahambing at hindi maibabalik sa sikretong pinagmulan nito.
Hindi magagamit ng hamon-tugon ang hash na may asin
Ang MSCHAPv2 ay isang palitan ng hamon-tugon, kaya hindi kailanman natatanggap ng server ang password at hindi maihahambing ang nakaimbak na string. Kailangan nitong kunin ang inaasahang tugon mula sa materyal na hawak na nito, at iyon ang dahilan kung bakit napakakitid ng mga katugmang nakaimbak na anyo. Ang halagang bcrypt o Argon2 na may asin kada gumagamit ay isang direksyon sa paraang tuluyang ibinubukod ang palitan. Ang talahanayan sa ibaba ay nagsisimula sa anyo ng imbakan at hindi sa pangalan ng paraan, dahil ang anyo ng imbakan ang nagtatakda ng sagot.
| 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 |
Ang dokumentasyon ng plugin na SQL para sa strongSwan ay nagtatakda ng sariling iskema para sa konpigurasyon at mga kredensyal, at minamarkahan pa rin ng proyekto ang pluging iyon bilang eksperimental. Wala sa loob nito ang umaangkop sa talahanayan ng mga gumagamit ng isang aplikasyon o humuhula kung aling iskema ng hashing ang gumawa ng nakaimbak na halaga. Kaya ang makatotohanang pagpipilian ay ang paglipat sa imbakang magagamit ng gateway, o isang serbisyo ng pagpapatotoo sa harap ng umiiral na imbakan na makapagsasagawa ng palitan. Anumang iba pa ay isang konektor na may nakatagong palagay sa loob.
Inililipat ng RADIUS ang trabaho, hindi ang pangangailangan
Ang pagdelegar ng EAP sa isang RADIUS server ay nagbabago kung saan nangyayari ang beripikasyon at karaniwang pinapabuti ang bakas ng pag-audit. Hindi nito naibabalik ang password mula sa isang direksyong hash, kaya ang serbisyo ng pagpapatotoo ay nangangailangan pa rin ng materyal na katugma ng paraang tinatapos nito. Natutuklasan ito ng mga koponan pagkatapos nilang itayo ang landas ng RADIUS at makaharap ang parehong pader sa kabilang dulo.
Kung saan mababasa ng RADIUS server ang isang direktoryo na may katugmang kredensyal, gumagana ang disenyo at nananatiling simple ang gateway ng VPN. Kung saan hindi nito kaya, ang tapat na sagot ay isang pagbabago sa pagpaparehistro at hindi isa pang konektor. Ang paglalaan at pagbawi ay pag-aari ng may-ari ng pagkakakilanlan, kaya ang kinopyang talahanayan na walang sinusuportahang proseso ng pag-sync ay ikalawang siklo ng buhay ng kredensyal at hindi isang pag-login lamang. Nawawala ito sa unang pagkakataon na may mag-reset ng password sa isang lugar lamang, at tahimik ang pagkakalayo hanggang sa ang account na umiiral sa dalawang sistema ay kumilos nang iba sa bawat isa.
Limitahan ang account na nagbabasa ng direktoryo sa pagbabasang iyon lamang, at panatilihin itong hiwalay sa account na ginagamit ng gateway para sa sarili nitong konpigurasyon. Ang pinagsasaluhang administratibong account ay ginagawang mas malawak na saklaw ng epekto ang isang disenyong basahin-lamang.
Saan dapat manirahan ang account
Kapag naayos na ang tanong sa materyal, dalawang arkitektura ang natitira. Maaaring magmay-ari ang gateway ng maliit na imbakan ng kredensyal na siya lamang ang nagbabasa, o maaaring magdelegar sa isang serbisyo ng pagpapatotoo na nakatayo sa harap ng direktoryo ng kumpanya.
Ang una ay mas madaling isipin at mas masama para sa gumagamit, na mauuwi sa ikalawang password na dapat alagaan. Ang pangalawa ay nagpapanatili ng isang pagkakakilanlan at nagdaragdag ng pagdepende sa isang serbisyong dapat tumatakbo na bago makakonekta ang sinuman. Wala sa dalawa ang mali, ngunit dapat itong itala sa tabi ng konpigurasyon ng gateway, dahil kung hindi ay ipagpapalagay ng susunod na inhinyero na ang isa pa ang pinili. Anuman ang piliin mo, ang dalawang utos sa ibaba ang nagpapakita ng kasalukuyang kalagayan bago mo ito baguhin.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsHindi rin naaayos ng pagpapatotoo ng account ang awtorisasyon. Ang pagiging miyembro ng grupo, kalagayan ng aparato at pahintulot sa network ay nangangailangan pa rin ng tahasang pagmamapa kapag napatunayan na ng gumagamit ang kinakailangang pagkakakilanlan. Ang koneksyong perpektong nagpapatotoo at walang awtorisasyon ay resulta ng patakaran, hindi depekto sa paraan.