EAP-metode eerste: watter wagwoordhash kan 'n VPN gebruik
'n VPN verifieer die geheim, nie die webhash nie. Lees die metode en kyk dan wat die stoor bevat voordat jy belowe dat dieselfde wagwoorde sal bly werk.
Baie spanne het 'n webaanmelding wat werk en 'n VPN wat elke wagwoord uit dieselfde tabel weier. Die webtoepassing vergelyk 'n hash wat dit self bereken het, terwyl die tonnel die kliënt vra om besit van 'n geheim te bewys op 'n manier wat die bediener moet kan nagaan. Dit is verskillende vereistes aan die gestoorde materiaal. Die gaping tussen hulle is waar die meeste van hierdie projekte tot stilstand kom.
Lees die metode, dan die skema
Skryf neer watter bewys die gekose metode vereis voordat jy na enige skema kyk. 'n Uitdagingsresponse-metode het materiaal nodig waaruit die bediener die verwagte respons kan bereken, wat in die praktyk die wagwoord of 'n versoenbare afgeleide vorm beteken. 'n Metode wat 'n wagwoord binne 'n beskermde tonnel dra, het die wagwoord self by die verifieerder nodig. Lees die metodedeokumentasie vir die verifieerdervereiste eerder as vir die kliëntkonfigurasie, want die kliëntvereistes is gewoonlik die maklike deel.
'n Gesoute hash wat deur 'n moderne webraamwerk geproduseer word, lewer nie een van die twee nie. Dit verifieer een spesifieke vergelyking en kan nie teruggedraai word na die geheim waaruit dit gekom het nie.
Uitdagingsresponse kan nie 'n gesoute hash gebruik nie
MSCHAPv2 is 'n uitdagingsresponse-uitruiling, so die bediener ontvang nooit die wagwoord nie en kan nie 'n gestoorde string vergelyk nie. Dit moet die verwagte respons aflei uit materiaal wat hy reeds het, en daarom is die versoenbare gestoorde vorms so eng. 'n bcrypt- of Argon2-waarde met 'n sout per gebruiker is eenrigting op 'n manier wat die uitruiling heeltemal uitsluit. Die tabel hieronder begin by die stoorvorm eerder as by die metodenaam, want die stoorvorm is wat die antwoord bepaal.
| 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 |
Die SQL-inprop-dokumentasie vir strongSwan definieer 'n eie skema vir konfigurasie en geloofsbriewe, en die projek merk daardie inprop steeds as eksperimenteel. Niks daarin pas by 'n toepassing se gebruikertabel aan of raai watter hashskema 'n gestoorde waarde geproduseer het nie. Die realistiese opsies is dus migrasie na 'n stoor wat die poort kan gebruik, of 'n verifikasiediens voor die bestaande stoor wat die uitruiling kan doen. Enigiets anders is 'n koppelvlak met 'n verborge aanname binne-in.
RADIUS skuif die werk, nie die vereiste nie
Om EAP aan 'n RADIUS-bediener te delegeer, verander waar verifikasie plaasvind en verbeter gewoonlik die ouditspoor. Dit herwin nie 'n wagwoord uit 'n eenrigting-hash nie, so die verifikasiediens het steeds materiaal nodig wat versoenbaar is met die metode wat dit termineer. Spanne vind dit uit nadat hulle die RADIUS-pad gebou het en dieselfde muur aan die ander kant tref.
Waar die RADIUS-bediener 'n gids kan lees wat 'n versoenbare geloofsbrief bevat, werk die ontwerp en bly die VPN-poort eenvoudig. Waar dit nie kan nie, is die eerlike antwoord 'n verandering aan die inskrywing eerder as nog 'n koppelvlak. Voorsiening en herroeping behoort aan wie die identiteit besit, so 'n gekopieerde tabel sonder 'n ondersteunde sinchronisasieproses is 'n tweede geloofsbrieflewensiklus eerder as enkelmeldingsaanmelding. Dit dryf die eerste keer weg wanneer iemand 'n wagwoord net op een plek herstel, en die wegdrywing is stil totdat 'n rekening wat in albei stelsels bestaan, in elke een anders optree.
Beperk die rekening wat die gids lees tot daardie lees, en hou dit apart van die rekening wat die poort vir sy eie konfigurasie gebruik. 'n Gedeelde administratiewe rekening verander 'n lees-alleen-ontwerp in 'n veel wyer ontploffingsradius.
Waar die rekening moet woon
Twee argitekture bly oor sodra die materiaalvraag besleg is. Die poort kan 'n klein geloofsbriefstoor besit wat net hy lees, of dit kan delegeer na 'n verifikasiediens wat voor die korporatiewe gids staan.
Die eerste is makliker om te beredeneer en slegter vir die gebruiker, wat met 'n tweede wagwoord eindig om in stand te hou. Die tweede hou een identiteit en voeg 'n afhanklikheid by van 'n diens wat nou op moet wees voordat enigiemand kan koppel. Nie een is verkeerd nie, maar die keuse moet langs die poortkonfigurasie aangeteken word, want die volgende ingenieur sal andersins aanvaar die ander een is gekies. Wat jy ook al kies, die twee opdragte hieronder is dié wat die huidige toestand wys voordat jy dit verander.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsRekeningverifikasie besleg ook nie magtiging nie. Groeplidmaatskap, toestand van die toestel en netwerktoestemming het steeds 'n eksplisiete kartering nodig sodra die gebruiker die vereiste identiteit bewys het. 'n Verbinding wat perfek verifieer en niks magtig nie, is 'n beleidsresultaat, nie 'n fout in die metode nie.