6.3. Az azonosítók életciklusa

Az előző fejezetekben bemutattuk a tipikus azonosítási élethelyzeteket és a gyakran használt azonosítókat. Most azt vizsgáljuk meg, hogy milyen események történnek egy azonosítóval annak létezésének idején. Elsősorban az általánosan jellemző eseményekre vagy olyanokra koncentrálunk, amely azonosítók széles osztályára érvényes. A fejezetben azt a szervezetet vagy alkalmazást, amely szolgáltatásai igénybe vételéhez az azonosítás szükséges röviden szolgáltatónak fogjuk nevezni.

6.2 ábra

A 6.2 ábra bemutatja a felhasználó életciklusát egy szervezeten belül. Az életciklus fázisait le kell képezni az azonosítók és a jogosultságok menedzselésében is. Ezeket az eseményeket követjük végig a fejezetben.

6.3.1. Regisztráció

Ha egy természetes vagy jogi személy, esetleg ezek egy csoportja – a továbbiakban ügyfél – elhatározza, hogy egy szolgáltatást igénybe vesz vagy kötelezik a szolgáltatás igénybe vételére, akkor kezdeményezi a szolgáltatónál a kapcsolatfelvételt. Ezt a szolgáltató el is utasíthatja, amikor a folyamat befejeződik. Pozitív válasz esetén kezdődhet az azonosító elkészítése. A kapcsolatfelvételt és az azonosító készítését regisztrációnak nevezzük és a szolgáltató részéről egy önálló szervezeti egység vagy – programok esetén – önálló modul végzi. A regisztráció során meg kell adni az előírt természetes azonosítókat, amelyeket a szolgáltató ellenőriz, és ha mindent rendben talál, akkor készülhet el az azonosító. Ha egy hivatalban történik a regisztráció, akkor az is készíti el az azonosítót, különben rendszerint az ügyfél adja meg azt. A regisztráló szervezet naplózza az aktust és szükség esetén tárolja az azonosító másolatát az ellenőrző szervezet adatbázisában. Az adatbázisban egyéb információt is tárolhatnak, közülük a leggyakoribbak az azonosító érvényességi ideje, a felhasználó szerepe vagy jogosultságainak listája. Egy felhasználóhoz tartozó rekord standard kereső kulcsát felhasználó névnek nevezzük.

Itt meg kell állnunk egy pillanatra. Az azonosítók másolatának tárolása a nem digitális azonosítók esetén természetes követelmény, mert lényegesen megkönnyíti az elveszett vagy megrongálódott azonosító pótlását. Kezdetben a digitális azonosítókat, például a jelszót is, kódolás nélkül tárolták. Arra figyeltek csak, hogy az adatbázist a memória nehezen hozzáférhető területén tárolják. Ez a megoldás azonban komoly veszélyforrás. Ha ugyanis egy hacker hozzáfér a szerverhez és megtalálja a jelszavakat tartalmazó adatbázist, akkor minden felhasználó azonosítója kompromittálódik, azaz minden felhasználónak új belépési kódot kell készíteni. Sokfelhasználós rendszereknél ez óriási költséggel és munkával jár.

A 90-es évektől kezdve a jelszavakat nem nyíltan, hanem egy egyirányú függvénnyel kódolva tárolják. Egy függvényt egyirányúnak nevezünk, ha a helyettesítési értékét gyorsan ki lehet számítani, de a helyettesítési értékből az argumentum értékét nagyon nehéz kiszámítani. Ilyen egyirányú függvénynek tekinthető a nyomtatott telefonkönyv, amelyben a tulajdonos ismeretében nagyon könnyű a telefonszámát kikeresni, de a telefonszámhoz nehéz annak tulajdonosát beazonosítani. Egyirányú függvényként például a DES-t vagy az ElGamal függvényt alkalmazzák, de a szolgáltatók saját fejlesztésű függvényt is alkalmazhatnak. Az azonosítók kódolásánál alkalmazott egyirányú függvényt hash függvénynek nevezzük.

Tagja vagyok az egyik legnagyobb magyar egészségpénztárnak, amely a portálján keresztül naprakész információt ad a tagok számlájának állásáról. Hosszabb ideig nem látogattam a portált és ahogy lenni szokott elfelejtettem a jelszavamat. E-mailen keresztül kértem, hogy új jelszót generálhassak. Az ügyintéző nagyon kedvesen, e-mail fordultával elküldte az elfelejtett jelszavamat. Szóval, az egyik legtöbb tagot kiszolgáló egészségpénztár 2009-ben kódolás nélkül tárolja a jelszavakat!

6.3.2. Ellenőrzés

Az azonosítót azért készítik, hogy igénybe vegyünk vele valamilyen szolgáltatást. Ez az azonosító érvényességi idején belül sokszor előfordul. Ilyenkor a szolgáltató ellenőrző funkciója működik. Az ügyfél azzal kezdeményezi a szolgáltatás igénybe vételét, hogy megadja a felhasználói nevét. Az azonosító bevitele annak típusától függ. A tudás alapú azonosítót például a személy írja be a számítógépbe, az eszköz alapút behelyezzük egy alkalmas olvasó berendezésbe. A viselkedés alapú azonosítás esetén pedig valamilyen érzékelő eszköz figyeli a személyt és alakítja át az észlelt jeleket a számítógép által feldolgozható formára.

Az azonosítók digitális mérete nagyon változó a jelszavak 40-64 bites méretétől, az 512-2048 bites aszimmetrikus kulcsokon keresztül, a több kilobájtos biometrikus azonosítókig terjed. Hasonlóan széles palettán mozog az ellenőrző eljárások bonyolultsága és ennek következtében sebességük is. Közös jellemzőjük azonban az, hogy a beolvasott azonosítót vagy azonosítókat az adatbázisban tárolt etalonnal hasonlítják össze. Nem kell azonban minden etalont végignézni, hanem csak azt vagy azokat, amelyek a felhasználó névhez tartozó rekordban vannak.

Jegyzetünk keretei nem teszik lehetővé, hogy minden azonosító típusra elemezzük az ellenőrzés folyamatát. Itt csak a jelszavas azonosításra koncentrálunk, mert ez a leggyakoribb elektronikus azonosítási módszer. Látni fogjuk, hogy már itt is sok problémába ütközünk.

6.3 ábra

A 6.3 ábrán bemutatjuk a jelszavas azonosítás alapesetét. Kriszta akarja magát azonosítani számítógépnek. Kriszta megadja a felhasználói nevét és a jelszavát. Mindkét adat kódolatlanul megy keresztül a csatornán! A számítógép megnézi, hogy a felhasználói név érvényes-e. Ha nem, akkor elutasítja a kérést. Különben megnézi, hogy a felhasználói névhez tartozó rekord jelszó mezőjében található adat megegyezik-e a Kriszta által megadott jelszóval. Ha nem, akkor ismét elutasítja a kérést, különben elfogadja, hogy Kriszta valóban felhasználó és használhatja a jogosultsági listájában megadott erőforrásokat.

Amint a regisztrációról szóló részben megjegyeztük ennek az eljárásnak nagy hibája, hogy a számítógép adatbázisában a jelszavakat kódolatlanul tárolják. Azt is leírtuk, hogy ha a regisztrációnál egy hash függvényt alkalmazunk, akkor ez a probléma kiküszöbölhető. Ha azonban a regisztrációkor nem a jelszavat, hanem annak kódolt változatát tároljuk, akkor ellenőrzéskor a Kriszta által megadott jelszóra ugyanezt a hash függvényt kell alkalmazni, mint amelyet a regisztrációkor használtak. A 6.4 ábra mutatja a módosított bejelentkezési eljárást.

Az azonosítás folyamata majdnem ugyanaz, mint az első esetben, különbség csak annyi, hogy a számítógép a Kriszta által megadott jelszónak a hash értékét hasonlítja össze az adatbázisában található adattal. A hash érték kiszámításához némi erőforrásra van szükség, de ez bőven megtérül azzal, hogy a jelszavak tárolása lényegesen biztonságosabb lett.

Ez a mechanizmus nagyon egyszerű és kielégíti a mindennapi élethez szükséges biztonsági követelményeket. További finomítás nélkül azonban már egy távoli számítógéphez való belépéskor vagy internetes banki tranzakciókor sem biztonságos. A hagyományos IP protokollok (ftp, http) ugyanis az adatokat eredeti formájukban továbbítják, így – esetünkben - a jelszót csak a fogadó számítógép kódolja. A jelszó tehát kódolatlanul utazik a nyilvános hálózaton. Némileg javít a helyzeten, ha már Kriszta számítógépe kiszámítja a jelszó hash értékét és csak az kerül a nyilvános csatornára. Ha ugyanis valaki hozzáfér a csatornán küldött üzenethez, akkor mindegy, hogy Kriszta jelszavát vagy csak annak hashelt változatát szerzi be, utóbbival ugyanúgy meg tudja személyesíteni Krisztát, mint a jelszóval.

A múlt század végén kidolgozott és egyre jobban terjedő, biztonságos IP protokollokkal (ssl, https) úgy oldható meg ez a probléma, hogy a jelszót aszimmetrikus titkosítással kódolva küldik át az ellenőrző számítógépnek. Az aszimmetrikus titkosítással a xxx. fejezetben fogunk foglalkozni. A számítógép a felhasználói név elfogadása után elküldi a tanúsítványát Krisztának. Kriszta ellenőrzi a tanúsítványt, és ha rendben találja akkor kinyeri belőle a számítógép nyilvános kulcsát. A jelszavára alkalmazza a hash függvényt, majd a számítógép nyilvános kulcsával kódolja a hash értéket. Az így kiszámolt adatot elküldi nyilvános csatornán a számítógépnek, amelyik a titkos kulcsával dekódolja az üzenetet, majd a kapott adatot, amelynek meg kell egyeznie Kriszta jelszavának hash értékével, összehasonlítja az adatbázisában tárolt adattal. Innentől kezdve a folyamat megegyezik az alapesetben leírtakkal. Az eljárást a 6.5 ábra mutatja.

6.5 ábra

A jelszavak biztonságos továbbításáért elég nagy árat kell fizetni. Az aszimmetrikus titkosítás ugyanis speciális szoftvert és komoly számítási erőt igényel. Később látni fogjuk, hogy a titkosítás és a visszafejtés külön-külön is körülbelül ezerszer lassúbb, mint a hash érték kiszámítása. A harmadik módszert tehát csak akkor érdemes bevetni, ha magas szintű biztonságot akarunk elérni és ez ki is fizetődik.

6.3.3. Azonosítók pótlása és visszavonása

A birtoklás alapú azonosítót el lehet veszíteni, ellophatják vagy annyira károsodhat, például kimoshatják vagy tűzbe esik, hogy használhatatlanná válik. Ilyenkor szükségessé válik annak visszavonása és új azonosítóval való pótlása. Az azonosító érvényességi idejének lejártával ugyanerre az aktusra kerül sor. A visszavonáshoz igazolni kell, hogy az azonosító valóban a miénk volt. Ha ez megtörténik, akkor az illetékes szervezet naplózza a visszavonás tényét az adatbázisába és általában új azonosítót állít ki.

A visszavonás végleges is lehet, ha a tulajdonos valamilyen ok miatt nem gyakorolhatja azokat a jogokat, amelyekre az azonosító felhatalmazta. Ilyen ok lehet, ha valaki meghal, olyan károsodást szenved, hogy nem vezethet járművet, kizárják egy szervezetből, stb. Ilyen esetekben tovább kell tárolni a visszavont azonosító másolatát, mert vissza lehet élni megszűnt vagy megszűntetett azonosítóval is. Nyikolaj Vasziljevics Gogol, Holt lelkek című regényének témája például az, hogy a főhős, Csicsikov, felvásárolja földesuraktól elhunyt jobbágyaikat. A regény végén kiderül, hogy mindezt azért teszi, hogy egy banktól nagy kölcsönt tudjon felvenni. Mire a bank kideríti, hogy a jobbágyok mind halottak, addig több év is eltelhet és a pénznek Csicsikovval együtt nyoma vész. A regény a XIX. században játszódik, amikor a nyilvántartások még nem voltak olyan hatékonyak, mint ma, de hasonló ötletekkel napjainkban is élhetnek a csalók.

Visszavonás után persze általában új azonosítót állítanak ki, amelynek folyamata azonos az eredeti azonosító elkészítésével.

Tudás alapú azonosítók érvényességi ideje is lejárhat, a munkahelyről kilépve megszűnhet a jogosultságunk az azonosítót elfelejthetjük vagy kompromittálódhat, azaz tudomást szerezhet róla arra illetéktelen személy. Ilyenkor válhat szükségessé az azonosító pótlása, cseréje vagy törlése.

Az elfelejtett azonosítók pótlásának eljárási rendje attól függ, hogy mennyire értékes az általa elérhető adattömeg. Nyilvános vagy személyes adat esetén elegendő az e-mail címünket megadni és arra elküldenek egy olyan ideiglenes azonosítót, amelyet az első bejelentkezéskor meg kell változtatni. Bizalmas és titkos adatok esetén a regisztrációnál alkalmazott eljárást kell megismételni.

Bizonyos alkalmazások megkövetelik a jelszavak rendszeres módosítását, sőt azt is, hogy az új jelszó nem lehet azonos a legutóbb használt néhány jelszóval. Ez az előírás növeli, de csökkenti is a biztonsági szintet. A munkahelyi rendszerbe való belépéshez használt jelszavaknál, amelyet naponta kell beírni a számítógépbe a megoldás nagyon hasznos, mert a néhány hétig vagy hónapig használt jelszó kisebb eséllyel kompromittálódik. Jelszavaink nagy részét azonban ritkán használjuk, így nincs alkalmunk a memorizálásra. Valamilyen módon mégis rögzítik a jelszavakat, például a mobiltelefonban tárolják, vagy egy noteszbe írják be, rossz esetben felírják egy öntapadó cédulára és azt felragasztják a monitorra. Egyik megoldás sem tökéletes, de a legutóbb említettől mindenkit eltanácsolunk.

Az adathalászok gyakran jelszavak frissítésére vagy ellenőrzésére kérik fel a gyanútlan felhasználót. Ilyen példákat láttunk az 1.2 és a 3.1 ábrákon. Az 1.2 ábrán mutatott laphoz egy kéretlen mailen keresztül jutottam el, amelyben az adathalászok megkértek a bank nevében, hogy a jelszavam ellenőrzése céljából lépjek be a bank rendszerébe. Számos hasonló példát lehetne még bemutatni. Ismételten felhívjuk az olvasó figyelmét, hogy ilyen kérésre ne reagáljanak, a szolgáltatók nem szokták e-mailben felszólítani az ügyfeleiket jelszavaik frissítésére.

Az elektronikus aláírás törvényről szóló 4.2 fejezetben rámutattunk arra, hogy az ellenőrző kulcsot a hitelesítés szolgáltatónak, a kulcs érvényességi idejének lejárta után még legalább öt évig meg kell őrizni. Hasonló a helyzet a bizalmas dokumentumok archiválásához használt titkos kulccsal. Ezeket addig kell megőrizni, amíg szükséges lehet a dokumentum dekódolására. A titkos kulcs és a titkosításához használt eszköz valamelyikének hiányában ugyanis ezeket a dokumentumokat nem lehet visszaállítani.