Së pari metoda EAP: cili hash fjalëkalimi mund të përdoret nga një VPN
Një VPN verifikon sekretin, jo hash-in e web-it. Lexoni metodën dhe më pas kontrolloni çfarë mban depozita përpara se të premtoni se të njëjtat fjalëkalime do të vazhdojnë të funksionojnë.
Shumë ekipe kanë një hyrje web që funksionon dhe një VPN që refuzon çdo fjalëkalim nga e njëjta tabelë. Aplikacioni web krahason një hash që e ka llogaritur vetë, ndërsa tuneli i kërkon klientit të provojë zotërimin e një sekreti në një mënyrë që serveri duhet të jetë në gjendje ta verifikojë. Këto janë kërkesa të ndryshme për materialin e ruajtur. Pikërisht në hendekun mes tyre ngecin shumica e këtyre projekteve.
Lexoni metodën, pastaj skemën
Shkruani çfarë prove kërkon metoda e zgjedhur përpara se të shikoni çdo skemë. Një metodë sfidë-përgjigje ka nevojë për material nga i cili serveri mund të llogarisë përgjigjen e pritur, që në praktikë do të thotë fjalëkalimi ose një formë e derivuar e përputhshme. Një metodë që e transporton fjalëkalimin brenda një tuneli të mbrojtur ka nevojë për vetë fjalëkalimin te verifikuesi. Lexoni dokumentacionin e metodës për kërkesën e verifikuesit dhe jo për konfigurimin e klientit, sepse kërkesat e klientit zakonisht janë pjesa e lehtë.
Një hash i kripur i prodhuar nga një framework modern web nuk ofron asnjërën. Verifikon një krahasim të vetëm të caktuar dhe nuk mund të kthehet mbrapsht në sekretin nga i cili doli.
Sfidë-përgjigja nuk mund të përdorë një hash të kripur
MSCHAPv2 është një shkëmbim sfidë-përgjigje, kështu që serveri nuk e merr kurrë fjalëkalimin dhe nuk mund të krahasojë një varg të ruajtur. Duhet ta nxjerrë përgjigjen e pritur nga materiali që tashmë e ka, dhe për këtë arsye format e ruajtura të përputhshme janë kaq të ngushta. Një vlerë bcrypt ose Argon2 me kripë për çdo përdorues është njëkahëshe në një mënyrë që e përjashton plotësisht shkëmbimin. Tabela më poshtë nis nga forma e ruajtjes dhe jo nga emri i metodës, sepse forma e ruajtjes është ajo që vendos përgjigjen.
| 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 |
Dokumentacioni i shtojcës SQL për strongSwan përcakton një skemë të vetën për konfigurimin dhe kredencialet, dhe projekti ende e shënon atë shtojcë si eksperimentale. Asgjë në të nuk përshtatet me tabelën e përdoruesve të një aplikacioni dhe as hamendëson se cila skemë hashimi e prodhoi një vlerë të ruajtur. Prandaj opsionet realiste janë migrimi në një depozitë që porta mund ta përdorë, ose një shërbim vërtetimi përpara depozitës ekzistuese që mund ta kryejë shkëmbimin. Çdo gjë tjetër është një lidhës me një supozim të fshehur brenda.
RADIUS e zhvendos punën, jo kërkesën
Delegimi i EAP-së në një server RADIUS ndryshon vendin ku bëhet verifikimi dhe zakonisht përmirëson gjurmën e auditimit. Nuk e rikuperon një fjalëkalim nga një hash njëkahësh, kështu që shërbimi i vërtetimit ka ende nevojë për material të përputhshëm me metodën që përfundon. Ekipet e mësojnë këtë pasi ndërtojnë rrugën RADIUS dhe ndeshen me të njëjtin mur në anën tjetër.
Aty ku serveri RADIUS mund të lexojë një drejtori me kredenciale të përputhshme, dizajni funksionon dhe porta VPN mbetet e thjeshtë. Aty ku nuk mundet, përgjigjja e ndershme është një ndryshim regjistrimi dhe jo një lidhës tjetër. Sigurimi dhe revokimi i përkasin atij që zotëron identitetin, prandaj një tabelë e kopjuar pa një proces sinkronizimi të mbështetur është një cikël i dytë jetësor i kredencialeve dhe jo një hyrje e vetme. Ajo shmanget herën e parë kur dikush rivendos një fjalëkalim vetëm në një vend, dhe shmangia është e heshtur derisa një llogari që ekziston në të dyja sistemet sillet ndryshe në secilin.
Kufizoni llogarinë që lexon drejtorinë vetëm në atë lexim dhe mbajeni të ndarë nga llogaria që porta përdor për konfigurimin e vet. Një llogari administrative e përbashkët e shndërron një dizajn vetëm-lexim në një rreze ndikimi shumë më të gjerë.
Ku duhet të jetojë llogaria
Pasi zgjidhet çështja e materialit, mbeten dy arkitektura. Porta mund të zotërojë një depozitë të vogël kredencialesh që vetëm ajo e lexon, ose mund t'ia delegojë një shërbimi vërtetimi që qëndron përpara drejtorisë së korporatës.
E para është më e lehtë për t'u menduar dhe më e keqe për përdoruesin, i cili mbetet me një fjalëkalim të dytë për të mirëmbajtur. E dyta ruan një identitet të vetëm dhe shton një varësi nga një shërbim që tani duhet të jetë aktiv përpara se dikush të lidhet. Asnjëra nuk është e gabuar, por zgjedhja duhet të regjistrohet pranë konfigurimit të portës, sepse përndryshe inxhinieri tjetër do të supozojë se është zgjedhur tjetra. Çfarëdo që të zgjidhni, dy komandat më poshtë janë ato që tregojnë gjendjen aktuale përpara se ta ndryshoni.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsVërtetimi i llogarisë nuk e zgjidh as autorizimin. Anëtarësimi në grup, gjendja e pajisjes dhe leja e rrjetit ende kanë nevojë për një hartëzim të qartë pasi përdoruesi të ketë provuar identitetin e kërkuar. Një lidhje që vërtetohet në mënyrë të përsosur dhe nuk autorizon asgjë është rezultat i politikës, jo një defekt në metodë.