Earst de EAP-metoade: hokker wachtwurdhash in VPN brûke kin
In VPN ferifiearret it geheim, net de webhash. Lês de metoade en kontrolearje dan wat it bewarplak befettet foardat jo belove dat deselde wachtwurden bliuwe wurkjen.
In protte teams hawwe in webynlogge dy't wurket en in VPN dy't elk wachtwurd út deselde tabel wegeret. De webapplikaasje ferliket in hash dy't er sels berekkene hat, wylst de tunnel de klant freget om besit fan in geheim te bewizen op in manier dy't de tsjinner kontrolearje moat. Dat binne ferskillende easken oan it bewarre materiaal. Krekt yn 'e kleau dêrtusken bliuwe de measte fan dizze projekten stykjen.
Lês earst de metoade, dan it skema
Skriuw op hokker bewiis de keazen metoade freget foardat jo nei hokker skema dan ek sjogge. In útdaging-antwurdmetoade hat materiaal nedich dêr't de tsjinner it ferwachte antwurd út berekkenje kin, wat yn 'e praktyk it wachtwurd of in kompatibele ôflate foarm betsjut. In metoade dy't it wachtwurd yn in beskerme tunnel draacht, hat it wachtwurd sels by de ferifiearder nedich. Lês de dokumintaasje fan 'e metoade foar de eask fan 'e ferifiearder en net foar de kliïntkonfiguraasje, want de klanteasken binne meastentiids it maklike part.
In sâlte hash dy't in modern webframework produsearret, leveret gjin fan beide. Hy ferifiearret ien spesifike ferliking en kin net werom nei it geheim dêr't er út kaam.
Útdaging-antwurd kin gjin sâlte hash brûke
MSCHAPv2 is in útdaging-antwurdútwikseling, dus de tsjinner krijt nea it wachtwurd en kin gjin bewarre tekenrige ferlykje. Hy moat it ferwachte antwurd ôfliede út materiaal dat er al hat, en dêrom binne de kompatibele bewarre foarmen sa nau. In bcrypt- of Argon2-wearde mei in sâlt per brûker is ienrjochting op in manier dy't de útwikseling folslein útslút. De tabel hjirûnder begjint by de bewarfoarm en net by de namme fan 'e metoade, want de bewarfoarm is wat it antwurd beslist.
| 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 |
De dokumintaasje fan 'e SQL-plug-in foar strongSwan definiearret in eigen skema foar konfiguraasje en bewiisstikken, en it projekt merket dy plug-in noch altyd as eksperiminteel. Neat dêryn past him oan by de brûkerstabel fan in applikaasje of riedt hokker hashskema in bewarre wearde makke hat. De realistyske opsjes binne dêrom migraasje nei in bewarplak dat it gateway brûke kin, of in ferifikaasjetsjinst foar it besteande bewarplak dy't de útwikseling dwaan kin. Al it oare is in ferbining mei in ferburgen oanname der yn.
RADIUS ferpleatst it wurk, net de eask
EAP oan in RADIUS-tsjinner deleezje feroaret wêr't de ferifikaasje bart en ferbetteret meastentiids it auditspoar. It hellet gjin wachtwurd werom út in ienrjochtinghash, dus de ferifikaasjetsjinst hat noch materiaal nedich dat kompatibel is mei de metoade dy't er beëiniget. Teams komme dêrefter nei't se it RADIUS-paad boud hawwe en oan 'e oare kant deselde muorre treffe.
Wêr't de RADIUS-tsjinner in gids lêze kin mei in kompatibel bewiisstik, wurket it ûntwerp en bliuwt it VPN-gateway ienfâldich. Wêr't er dat net kin, is it earlike antwurd in feroaring yn 'e ynskriuwing ynstee fan noch in ferbining. Foarsjenning en ynlûken hearre by wa't de identiteit hat, dus in kopiearre tabel sûnder in stipe syngronisaasjeproses is in twadde libbenssyklus fan bewiisstikken ynstee fan ien inkelde oanmelding. Hy rint útinoar de earste kear dat immen in wachtwurd mar op ien plak weromset, en it útinoarrinnen is stil oant in akkount dat yn beide systemen bestiet him yn elk oars gedraacht.
Behein it akkount dat de gids lêst ta krekt dy lêzing, en hâld it apart fan it akkount dat it gateway foar syn eigen konfiguraasje brûkt. In dield administratyf akkount makket fan in lês-allinnesûntwerp in folle bredere ynfloedsradius.
Wêr't it akkount wenje moat
As de materiaalfraach beslist is, bliuwe der twa arsjitektueren. It gateway kin in lyts bewarplak foar bewiisstikken hawwe dat allinnich hy lêst, of it kin deleezje oan in ferifikaasjetsjinst dy't foar it bedriuwsgids stiet.
De earste is makliker te beriedenerjen en slimmer foar de brûker, dy't mei in twadde wachtwurd oerbliuwt om te ûnderhâlden. De twadde hâldt ien identiteit en foeget in ôfhinklikens ta fan in tsjinst dy't no oan wêze moat foardat immen ferbine kin. Gjin fan beide is ferkeard, mar de kar moat by de gatewaykonfiguraasje fêstlein wurde, want oars sil de folgjende yngenieur oannimme dat de oare keazen is. Wat jo ek kieze, de twa opdrachten hjirûnder binne dejinge dy't de hjoeddeistige tastân sjen litte foardat jo dy feroarje.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsAkkountferifikaasje beslist ek de autorisaasje net. Groeplidmaatskip, tastân fan it apparaat en netwurkfergunning hawwe noch in eksplisite mapping nedich as de brûker de easke identiteit bewiisd hat. In ferbining dy't perfekt ferifiearret en neat autorisearret is in beliedsresultaat, gjin flater yn 'e metoade.