Sajnálatos módon azonban ez nem így van. Erre az USA szabványügyi és technológiai intézete (NIST) már több mint 15 éve felhívta a figyelmet. Egy 2006-os publikációjukban azzal számoltak, hogy egy a felhasználó által szabadon választott jelszó első 8 karaktere még 4-4 bit entrópiát jelent, ám a 20. karakterig bezárólag az újabb karakterek már csak 2-2, míg a 21. karaktertől mindössze 1,5 bitet képesek hozzáadni a jelszó entrópiájához. A gyakorlatban ez azt jelenti, hogy a hosszabb jelszavaknál egy újabb karakter hozzáadása egyre kisebb mértékben növeli a biztonságot.

Az NIST azzal számolt, hogy a kis- és nagybetűk, illetve a nem alfanumerikus karakterek vegyes használatának kikényszerítése extra 6 bittel növeli az entrópiát, sőt ha ellenőrizzük, hogy szótári szavak ne szerepeljenek a jelszóban, az átlagosan további 4 bit entrópiát jelenthet. Ezeket az entrópiaértékeket alapul véve azt lehet mondani, hogy érdemes a felhasználókat 8 karakternél hosszabb, komplex jelszavak használatára kényszeríteni, ami megfelel a szakma régi mantrájának.

Nem meglepő tehát, hogy ez az elv makacsul tartotta magát annak ellenére is, hogy a Carnegie Mellon Egyetem már egy bő évtizede publikálta azt a kutatását, melynek eredményei komolyan alá kellett volna ássák ezt a hiedelmet. A kutatás szakított a hagyománnyal, és a jelszavak biztonságát nem az elmélet, azaz az entrópia felől közelítette meg, hanem az ellenálló-képességet vizsgálta a különböző, a gyakorlatban a támadók által is használt, heurisztikus jelszótörési módszerekkel szemben.

A kutatók az egyes jelszavakat kategóriákba sorolták. Ezen kategóriák közül az egyik (comprehensive8) kritériumai – nem meglepő módon – egybeestek a régi mantra kritériumaival. Csakhogy számos egyéb mellett volt olyan kategória (basic16) is, ahol csak annak a kritériumnak kellett megfelelni, hogy a jelszó legalább 16 karakter hosszú legyen. Utóbbi esetben semmilyen egyéb feltétel nem volt, akár állhatott kisbetűsen írt szótári szavakból is.

Az elemzés több tanulsággal is szolgált ezen kategóriákkal kapcsolatban, illetve a kategóriákon túlmenően is. A tanulmány általános megállapítása, hogy az entrópia értéke csak laza korrelációt mutat a törési módszereknek való ellenálló-képességgel. Vagyis nem állapítható meg oksági összefüggés a kettő között. A korábbiak fényében nem meglepő, hogy kiderült: a jelszavak heurisztikus megtippelési módszereit felhasználó védelmi technikák hatékonyabbak, mint a szótárak alkalmazása az egyszerű jelszavak kiszűrésére. Talán a legfontosabb megállapítás, ami jelen cikk inspirációját is adta, hogy a hosszabb, de kevésbé komplex jelszavak (basic16) legalább olyan hatékonyan állnak ellen a támadásoknak, mint rövidebb, de komplexebb (comprehensive8) társaik.

A biztonság van az emberért, és nem fordítva

Felmerül tehát a kérdés, hogy érdemes-e minden biztonsági rendszer leggyengébb pontját – az embert – olyan helyzetbe kényszeríteni, amiben már inkább a rendszer kijátszásában érdekelt, ahelyett, hogy egy számára is elfogadható, de egyúttal a biztonságot is garantáló, módszer mentén a rendszer keretein belül tartanánk. A felhasználó találékonyságát soha nem érdemes lebecsülni, főképp akkor nem, amikor bárki két kattintásnyira van attól, hogy a mobilinternetét felhasználva kikerülje a céges tűzfalat.

Bizonyos árnyékinformatikai megoldások alkalmazására ma már nem csak magasan képzett szakemberek képesek. Ennek épp az a veszélye, hogy a biztonságért felelős kollégák nem tudnak olyan felhasználási módokról, amikről pedig tudniuk kellene. A jelszavak esetén kézenfekvő példa a jelszó monitorra való felragasztása, ami vélhetőleg a legtöbb helyen nem csak a józan észnek, de a szabályzatnak is ellentmond. Ha viszont a felhasználó egy olyan szintre jut, ahol nem tudja, mi lenne ennél jobb megoldás, akkor mindenki veszít. Hiába van egy körültekintően megírt szabályzat, ha a gyakorlat azzal szembe megy. Hiába fogalmazza meg a szabályzat a jogi felelősséget, a szabályzat be nem tartása esetén, ha a keletkezett kár nagyságrenddel nagyobb, mint amit behajtani képes a szervezet.

Bár a kontrollok nem tudják teljeskörűen megoldani a problémákat, lemondanunk nem kell (és nem is okos) róluk. Annak tudatosítása azonban elengedhetetlen, hogy a szabályzataink bizonyosan nem terjednek ki mindenre, de ha mégis, egyes részeinek ellenőrzése egész egyszerűen nem áll módunkban. Márpedig minden szabály annyit ér, amennyire azt be lehet tartatni. A legjobb példa a szabályok korlátosságára az a statisztika, mely szerint a felhasználók 99 százaléka használja ugyanazokat a jelszavakat a szervezeten belül és azon kívül. Erre ráadásul már csak akkor derül fény, amikor egy adott felhasználó interneten igénybe vett szolgáltatási fiókjának kompromittálása után a céges fiók kompromittálása is megtörténik, Vagyis amikor már késő. Különösen nagynak tűnhet a baj, ha figyelembe vesszük, hogy egy sikeres adathalász akció után a privát adatokhoz való hozzáférés medián ideje 72 perc (a Microsoft egy friss tanulmánya szerint).

A hangsúlyt tehát, mint annyi egyéb helyen is, a prevencióra érdemes helyezni. Az ellenálló-képesség csak részben technikai kérdés, sok múlik a humán faktoron. A felhasználók oktatása szükséges ugyan, de nem elégséges. Hiába tudja valaki, hogy nem okos megosztani jelszavakat, sőt tilos is, ha a gyakorlatba ez nem megy át. Példának okáért azért, mert nincs meg az a kooperatív szellem, amiben a felhasználó fontosnak érezné nem kockáztatni a szervezet biztonságát. Lehet, hogy mindez azért van, mert nem látja át a kockázat valós mértékét, de ok lehet az is, hogy nincs tudása arról, hogyan tud megjegyezhető jelszavakat generálni magának kellő számban.

Hogy válasszunk jelszót cégen belül és kívül?

A belső rendszerekben a rugalmasság és a biztonság összhangba hozása már csak azért is fontos, mert a külső rendszereken nincs módunk változtatni, vagyis a felhasználó már így is számos helyen kénytelen olyan jelszavakat használni, melyek számára bonyolultak. Azaz könnyen eshet kísértésbe, hogy ha már egyet sikerült közülük megjegyeznie, azt használja majd a céges fiókjánál is. Sajnos még a közelmúltban is lehetett arra példát látni, hogy a jelszó mérete nem csak alulról, de felülről is korlátos volt, vagyis az amúgy biztonsági szempontból kritikus rendszer nem fogadott el 16 karakternél hosszabb jelszót. Ennél már csak az a rendszer volt meglepőbb, amikor ugyan látszólag elfogadta a hosszabb jelszót, de tárolásra csak az első 12 karakter került. Ezek a hibák az általunk kontrollált rendszerekben elkerülhetők.

Biztassuk a felhasználókat olyan jelszavak, illetve még inkább jelmondatok használatára, melyek kellő biztonságot adnak, de mégis megjegyezhetők. Ezzel elkerülhetők az olyan köznapi, de súlyos hibák, mint hogy a jelszó "biztonsági másolata" egy cetlin van a monitorra ragasztva.

Az NIST 2017-ben közzétett iránymutatása szerint egy jelszó legyen legalább 8 karakter hosszú, további komplexitásra vonatkozó megkötésekre azonban nincs szükség, legalábbis olyan jelszavak esetén, amit egy felhasználónak meg kell tudnunk jegyezni. A jelszavak ellenőrzésénél ugyanakkor érdemes szűrni a szótári szavakat, az ismerten rossz jelszavakat (pl. qwerty, passwd, Password1! stb.), az ismétlődéseket (pl. 1234, aaaaa), a korábban már kiszivárgott jelszavakat, illetve a kontextusra (cégnév, alkalmazás neve stb.) utaló szavakat, amikkel egy támadó elsőként fog próbálkozni.

A belső rendszereknél alkalmazhatunk korlátokat a belépési próbálkozásokra vonatkozóan. A könnyen megjegyezhető jelszavak előnye itt is megmutatkozik, hiszen egy komplex jelszó esetén könnyebben ejtünk hibát annak felidézésekor. Bár fentebb bemutattuk, hogy a többfaktoros azonosítás sem csodaszer, léteznek olyan hardveres megoldások, mint például a tokenek, amik egy mobil eszköz védelmi szintjét jócskán felülmúlják. Persze ezek a megoldások az eszközök közvetlen ára és integrációs költsége miatt csak a magasabb biztonsági igényű rendszereknél relevánsak.

Vélhetőleg a szervezeten belül és azon kívül egyaránt lesznek olyan helyzetek, amikor komplex jelszavak használatára leszünk kényszerítve. Ezen helyzetekre nyújthat megoldást valamilyen jelszókezelő alkalmazás, amely képes minden egyes oldalhoz véletlenszerű jelszót generálni, majd azt tárolni, és egy későbbi bejelentkezés során újra használni. Az ilyen eszközöknél azonban nem feledkezhetünk meg arról, hogy végső soron minden jelszavunkat az a jelszó védi, amit a jelszókezelőbe való bejelentkezéshez használunk. A felhőalapú megoldásoknál ráadásul jelszavaink egy harmadik félnél tárolódnak, vagyis már nem csak annál a szolgáltatónál kompromittálódhatnak, ahol a bejelentkezéshez szeretnénk használni őket, hanem ott is, ahol kényelmi okoknál fogva tároljuk őket.

Az igazán jó megoldás, amikor a jelszavak nincsenek tárolva, vagy legalábbis a tárolás során nem kötődnek hozzánk. Utóbbira zseniális, bár mégsem követendő, a Jóbarátok sorozat egyik szereplőjének azon módszere, hogy a PIN kódját a sarki automata üvegébe véste be, ami neki segített a megjegyzésben, egy támadót mégsem juttatott előnyhöz.

Véletlenszerűnek tűnő jelszavak nagy számban való előállításához használhatunk jelszó generátorokat, ahol csupán egy mester jelszót kell megjegyeznünk, a szoftver pedig ennek, illetve a bejelentkező oldal címének felhasználásával egy, csak az oldalra jellemző jelszót generál.

Akármennyire is joggal hangsúlyozzuk a kellő biztonságú jelszavak fontosságát, arról nem feledkezhetünk meg, hogy nem ez az első, és persze nem is az utolsó lépés egy rendszer biztonságos működésének biztosításánál. A legkiválóbb jelszó sem ér semmit ugyanis, ha annak bizalmasságát mi magunk kockáztatjuk azzal, hogy nem követelünk meg minden bejelentkezésnél titkosítást, vagy ha felesleges jogosultságokat rendelünk egy felhasználói fiókhoz.

Még a leggyengébb jelszó sem feltétlenül probléma, ha annak kompromittálására időben fény tudunk deríteni, és a jogosulatlan hozzáférést azonnali automatizált beavatkozással meg tudjuk akadályozni. A cél tehát nem csupán egy biztonságos jelszó, hanem a felhasználó azonosítása, a neki (feltétlenül) szükséges erőforrások biztosítása, a rendszer folyamatos megfigyelése, a szükséges beavatkozások megtétele mellett.

Pfeiffer Szilárd
A szerző fejlesztő, IT-biztonsági szakértő, a Balasys munkatársa. Évekig dolgozott a Zorp tűzfal fejlesztésén. Jelenleg cége IT-biztonsági evangelistája. Legutóbbi írása a Bitporton itt olvasható.