In VPN-autentikaasjebackend migrearje sûnder âlde hashes opnij te brûken

Brûkersnammen ferskine yn it nije register, de migraasje wurdt foltôge ferklearre, en oanmeldingen mislearje dochs. De gateway hat noch altyd in stipe autentikaasjepaad en in korrekt autorisaasjerisseltaat nedich, en gjin fan beide folget út in register dat no de akkounts befettet. In backendferhuzing is in oergong mei in libbenssyklus, gjin kopyopdracht. It symptoom hjirûnder is it symptoom dat it ferskil meastentiids blootleit.

It symptoom: akkounts besteane, sesjes net

It nije register befettet elke brûkersnamme, in testbind slagget, en de VPN-klant jout noch altyd in autentikaasjeflater. Dy kombinaasje betsjut dat de identiteit bestiet, mar dat it ferifikaasjepaad dat de gateway brûkt dy net berikt, of berikt mei in metoade dêr't net oan foldien wurde kin. Beide binne konfiguraasje, en it binne ferskillende problemen.

It earste is bekabeling: de gateway wiist nei in backend dy't net antwurdet, brûkt in dield geheim dat de oare kant net ferwachtet, of freget om in attribút dat de nije tsjinst net weromjout. It twadde is kryptografysk: de metoade easket it oarspronklike geheim, en it nije bewarplak hat allinnich in hash dêrfan. De flatertekst liket yn beide gefallen op inoar, en dêrom wurde de twa as ien probleem behannele.

Dy twa skiede foardat akkounts oanrekke wurde, sparret in wike. It iene is in fraach oer rûteleas en fertrouwen, it oare is in beslút oer it resetten fan oanmeldgegevens, en se trochinoar helje jout feroarings dy't nimmen taskriuwe kin.

Kartografearje de keat foardat immen ferhúzet

Skriuw foar elk klantprofyl seis dingen op: de bûtenste autentikaasjemetoade, in eventuële binnenmetoade, de tsjinneridentiteit dy't de klant ferwachtet, de ynterface tusken gateway en backend, it attribút dat de gateway op groepsliemskip ôfbyldet, en it resultearjende boarnbelied. Se yn folchoarder lêze lit sjen hokker skeakel nimmen hat. Elk item hat in eigner, en de oergong mislearret by dy't nimmen kontrolearre hat.

In gewoane registeroanmelding trochrint hast neat fan dy keat. Se bewissiget dat it akkount bestiet en it wachtwurd wurket, en dat is krekt it diel dat nea twivelich wie.

Hashes reizgje net tusken metoaden

Kompatibiliteit fan oanmeldgegevens moat ien kear kontrolearre wurde, foardat in groep ferhúzet. FreeRADIUS dokumintearret de splitsing dúdlik: in CHAP-kontrôle dy't de tsjinner sels útfiert hat it werklike wachtwurd nedich, en MS-CHAP akseptearret dat wachtwurd of geskikt NT-materiaal. In hash dy't foar in oar doel makke is, past by gjin fan beide gefallen, hoe sterk dy ek is.

It ferskil giet oer wa't it bewiis berekkenet. In metoade dy't ferifiearret troch oan it register te binen, lit it register kontrolearje wat it kontrolearje kin. In metoade dy't ferifiearret troch in útdagingsantwurd opnij te berekkenjen, hat it geheim sels nedich, om't de tsjinner deselde berekkening útfierde moat.

Dêr't it materiaal ûntbrekt, binne de earlike opsjes in stipe reset, opnij ynskriuwe, in eksterne ferifikaasjetsjinst of in metoadeferoaring. In tydlike eksport fan weromhelbere wachtwurden stiet net op dy list. It makket in bewarplak fan oanmeldgegevens yn platte tekst yn 'e meast chaotyske wike fan it projekt, en it oerlibbet de migraasje meastentiids.

Pilotgroep, dan feroarings yn 'e libbenssyklus

Ferhúzje in lytse groep goedkarde identiteiten mei de echte klant, en test fjouwer dingen: in farske oanmelding, in mei opset ferkearde oanmeldgegevens, de boarnen dy't de sesje berikke mei, en de boarnen dy't se net berikke mei. Kontrolearje ek de tsjinneridentiteit dy't de klant akseptearre hat, want in ôfwikende sertifikaatnamme bliuwt ûnsichtber oant immen it klantlog lêst.

Trochrin dan de feroarings dêr't de útrôl echt fan ôfhinget. Feroarje in wachtwurd, fernij of skriuw in sertifikaat opnij yn, en ferwiderje tagong fan ien pilotakkount. Befêstigje nei elk dêrfan hokker ferifiearder de poging behannele hat, want in sesje dy't foar de oergong makke is kin trochwurkje en bewissiget neat oer de folgjende oanmelding.

Skied profyllevering fan 'e identiteitsoerstap. Elke groep hat syn bedoelde profyl nedich, syn status fan oanmeldgegevens of ynskriuwing, de autentikaasjetsjinst dy't er brûke moat en in supportkontakt, en gjin fan dy gegevens mei in geheim befetsje.

As âlde en nije paden njonken inoar bestean, behein se dan mei in einddatum. In automatyske weromfal kin in akkount fia âlde oanmeldgegevens binnenlitte nei't de nije eigner de tagong fuorthelle hat, en dat is in feiligensregresje ferklaaid as beskikberens.

In weromrôlje kin gjin oanmeldgegevens weromsette

It weromdraaien fan 'e oergong lit it register krekt sa't it no stiet. In resette wachtwurd bliuwt resette, in ynlutsen sertifikaat bliuwt ynlutsen, en in feroare formaat fan oanmeldgegevens bliuwt feroare. Dat binne foarfallen yn it register, en de gateway wie der nea de boarne fan. Retten moat per foarfal definiearre wurde, en neat dêrfan mei ôfhingje fan it rekonstruearjen fan in geheim út in ynkompatibele hash.

Hâld in administratyf paad oan dat net de ferbining brûkt dy't migrearre wurdt. As de nije autentikaasje mislearret, pauzearje de groep en brûk it dokumintearre retpaad ynstee fan de autentikaasje foar elkenien te ferswakjen om in deadline te heljen.

Nei't de groepen ôfdutsen binne, weromlûke de âlde backend-oanmeldgegevens, profylen en fertrouwensrelaasjes fia har eigners. Befêstigje dat it âlde paad gjin brûkers mear talit, en hâld de net-geheime keppeling fan identiteit oan belied dy't support noch nedich hat. In migraasje is klear as de nije libbenssyklus wurket en nimmen mear fia it âlde paad binnenkomt, net as de akkountlist folslein liket.