Unue la metodo EAP: kiun pasvortan haketon VPN povas uzi
VPN kontrolas la sekreton, ne la retan haketon. Legu la metodon, poste kontrolu kion la konservejo enhavas antaŭ ol promesi ke la samaj pasvortoj plu funkcios.
Multaj teamoj havas retan ensaluton kiu funkcias kaj VPN-on kiu rifuzas ĉiun pasvorton el la sama tabelo. La reta aplikaĵo komparas haketon kiun ĝi mem kalkulis, dum la tunelo petas la klienton pruvi posedon de sekreto tiamaniere ke la servilo povu kontroli. Tiuj estas malsamaj postuloj pri la konservita materialo. Ĝuste en la breĉo inter ili plej multaj el tiuj projektoj haltas.
Unue la metodo, poste la skemo
Notu kiun pruvon la elektita metodo postulas antaŭ ol rigardi ajnan skemon. Metodo de defio kaj respondo bezonas materialon el kiu la servilo povas kalkuli la atendatan respondon, kio praktike signifas la pasvorton aŭ kongruan derivitan formon. Metodo kiu portas la pasvorton ene de protektita tunelo bezonas la pasvorton mem ĉe la kontrolanto. Legu la dokumentaron de la metodo por la postulo de la kontrolanto, ne por la klienta agordo, ĉar la klientaj postuloj kutime estas la facila parto.
Sala haketo produktita de moderna reta kadro provizas nek unu nek la alian. Ĝi kontrolas unu specifan komparon kaj ne povas esti returnita al la sekreto el kiu ĝi venis.
Defio kaj respondo ne povas uzi salan haketon
MSCHAPv2 estas interŝanĝo de defio kaj respondo, do la servilo neniam ricevas la pasvorton kaj ne povas kompari konservitan ĉenon. Ĝi devas derivi la atendatan respondon el materialo kiun ĝi jam posedas, kaj tial la kongruaj konservitaj formoj estas tiel mallarĝaj. Valoro bcrypt aŭ Argon2 kun salo por ĉiu uzanto estas unudirekta tiel ke ĝi tute ekskludas la interŝanĝon. La tabelo sube ekas de la konserva formo, ne de la nomo de la metodo, ĉar la konserva formo decidas la respondon.
| 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 |
La dokumentaro de la SQL-kromprogramo por strongSwan difinas propran skemon por agordo kaj akreditaĵoj, kaj la projekto ankoraŭ markas tiun kromprogramon eksperimenta. Nenio en ĝi adaptiĝas al la uzula tabelo de aplikaĵo aŭ divenas kiun haketan skemon produktis konservitan valoron. La realismaj elektoj do estas migrado al konservejo kiun la enirejo povas uzi, aŭ identiga servo antaŭ la ekzistanta konservejo kiu povas plenumi la interŝanĝon. Ĉio alia estas konektilo kun kaŝita supozo ene.
RADIUS movas la laboron, ne la postulon
Komisii EAP al RADIUS-servilo ŝanĝas kie okazas la kontrolo kaj kutime plibonigas la revizian postsignon. Ĝi ne rekuperas pasvorton el unudirekta haketo, do la identiga servo ankoraŭ bezonas materialon kongruan kun la metodo kiun ĝi finas. Teamoj malkovras tion post kiam ili konstruis la RADIUS-vojon kaj renkontis la saman muron ĉe la alia flanko.
Kie la RADIUS-servilo povas legi dosierujon enhavantan kongruan akreditaĵon, la dezajno funkcias kaj la VPN-enirejo restas simpla. Kie ĝi ne povas, la honesta respondo estas ŝanĝo de aliĝo, ne alia konektilo. Provizado kaj revoko apartenas al tiu kiu posedas la identecon, do kopiita tabelo sen subtenata sinkroniga procezo estas dua vivciklo de akreditaĵoj, ne ununura ensaluto. Ĝi malkongruiĝas la unuan fojon kiam iu restarigas pasvorton nur en unu loko, kaj la malkongruo restas silenta ĝis konto ekzistanta en ambaŭ sistemoj kondutas malsame en ĉiu.
Limigu la konton kiu legas la dosierujon al ĝuste tiu legado, kaj tenu ĝin aparta de la konto kiun la enirejo uzas por sia propra agordo. Komunigita administra konto transformas nurlegan dezajnon en multe pli larĝan efikradiuson.
Kie la konto devus loĝi
Post kiam la materiala demando estas solvita, restas du arkitekturoj. La enirejo povas posedi malgrandan konservejon de akreditaĵoj kiun nur ĝi legas, aŭ ĝi povas komisii identigan servon kiu staras antaŭ la entreprena dosierujo.
La unua estas pli facile pripensebla kaj pli malbona por la uzanto, kiu finas kun dua pasvorto por prizorgi. La dua konservas unu identecon kaj aldonas dependecon de servo kiu nun devas esti funkcianta antaŭ ol iu ajn povas konekti. Neniu estas malĝusta, sed la elekto devus esti registrita apud la enireja agordo, ĉar alie la sekva inĝeniero supozos ke la alia estis elektita. Kion ajn vi elektos, la du komandoj sube estas tiuj kiuj montras la nunan staton antaŭ ol vi ŝanĝos ĝin.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKonta identigo ankaŭ ne solvas rajtigon. Grupa membreco, aparata stato kaj reta permeso ankoraŭ bezonas eksplicitan mapadon post kiam la uzanto pruvis la postulatan identecon. Konekto kiu identiĝas perfekte kaj rajtigas nenion estas politika rezulto, ne cimo en la metodo.