Van egy ortodox irányzat a jelszavak kapcsán, amely szerint az a jó, ha a jelszavak hosszabbak, minél összetettebbek, és azokat minél gyakrabban cseréljük. Valóban ettől lesznek a rendszereink biztonságosabbak? Vagy esetleg létezik más progresszív megközelítés, amely a megkerülhetetlen emberi sajátosságokat is figyelembe veszi? Hogy a jelszavak problémája milyen mélyen él velünk, mi sem példázza jobban, mint hogy a közelmúltban Magyarországon és külföldön egyaránt történt nem egy olyan, nagy nyilvánosságot kapott biztonsági incidens, amelynek kiindulópontja vélhetőleg a jelszavak kompromittálása volt.
Ezek az események nem kiragadott példák. Jól illeszkednek egy nemzetközi trendbe. Hosszú évekre visszamenőleg számos olyan incidenst tudnánk felsorolni, melyek a jelszavak – vagy más azonosításra használt adatok – helytelen kezelésére vezethetők vissza. A helytelen kezelés sokféleképp megvalósulhat. Ezek közül néhányra ráadásul semmilyen ráhatása sincs egy adott szervezetnek; még akkor sem, ha a szervezet erre vonatkozó szabályzata alapos, és következetesen betartatják. Példának okáért a Balbix 2022-es tanulmánya szerint (PDF) a felhasználók 99 százaléka használja ugyanazokat a jelszavakat munkahelyi és magán célokra. Ez a felhasználói gyakorlat eleve magában hordozza annak kockázatát, hogy amikor egy magáncélú fiók támadás áldozatává válik, akkor az a céges fiókot is kitetté teszi, hiszen a támadó első dolga lesz a céges környezetben kipróbálni a megszerzett jelszót, illetve annak variánsait.
Bár a vállalati szabályzatok számos esetben tiltják a céges jelszavak szervezeten kívüli használatát, a példa jól mutatja, hogy a helyzet pusztán jogi eszközökkel kezelhetetlen, legfeljebb a felelősség áthárítására alkalmas. Természetesen ez a szempont sem elhanyagolandó, különös tekintettel arra, hogy az adatszivárgások számos esetben lopott jelszavakra vezethetőek vissza. A Verizon adatszivárgásokkal foglalkozó tanulmánya (PDF) a webes szolgáltatásokat ért támadások esetén 80 százalékban jelöli meg ezt okként. Éppen ezért célszerű kellő fenntartással viszonyulnunk a szabályzatok azon pontjaihoz, melyek betartatására nincsenek érdemi eszközeink.
Az elmélet és gyakorlat különbsége
Ugyanakkor az óvatosság akkor sem haszontalan, ha a jelszóhasználati szabályzat betartatásának eszközei látszólag a kezünkben vannak. Erre példa a vállalati rendszereken belül használt jelszavak paraméterei – hossz, komplexitás, ismétlések –, valamint az érvényességi idő maximalizálása. Egy jól felépített informatikai rendszerben ezen paraméterek minden további nélkül kikényszeríthetők, mégis csak első látásra vezetnek a jó irányba. A jelszavak védelmi erejének kulcsa ugyanis nem a komplexitás, hanem a megjósolhatatlanság. Vagyis ha a legkevésbé kitalálható egy jelszó, annak ismeretében, hogy annak ki a birtokosa, vagy mik voltak a korábbi jelszavak, akkor vagyunk a legnagyobb biztonságban.
Ezen megjósolhatatlanság leírására szolgál az entrópia. Minél nagyobb az entrópia, annál több véletlenszerű tippre van szükség a jelszó kitalálásához. Az entrópia növelésére önmagában véve a jelszó komplexitásának növelése jobbára csak elméletben alkalmas.
Entrópia
Az entrópia egy rendszer rendezetlenségi fokának mértéke. Jelszavak esetén ez annyit tesz, hogy minél magasabb a rendezetlenség foka, annál kevésbé használhatók heurisztikus módszerek egy jelszó kitalálására. Marad tehát a nyers erő, ahol minden egyes lehetőséget végig kell próbálni. Ez egy CVC vagy PIN kód esetén, ahol a lehetséges variációk száma alacsony, még működőképes is, de a jelszó hosszának, illetve bonyolultságának növelésével az ehhez szükséges idő és erőforrásigény akkorára nő, hogy feltörése a támadónak már nem éri meg.
Az említett rendezetlenségi fok kifejezésére egy számértéket használunk, melynek mértékegysége a bit. Egy CVC kód, ami 3 számjegyből áll, entrópiája közelítőleg 10 bit, míg egy 6 számjegyű PIN kódé hozzávetőleg 20 bit. Az entrópia egyetlen bittel való növelése a nyers erővel való feltörés erőforrásigényét minden esetben duplázza. Az előbbi példában 3 plusz számjegy 10 bitnyi plusz entrópiát jelentett, vagyis a feltöréshez szükséges idő az 1024-szeresére növekszik. Ha számjegyek helyett latin kisbetűket használunk, akkor egy-egy új betű 4,7 bit extra entrópiát, vagyis 26-szoros (kisbetűk száma) számításigényt jelent, a speciális karaktert hozzáadva ez 5 bit, vagyis a számítási igény növekedése elméletben 32-szeres.
Vegyük például azt a sokat hangoztatott elvet, miszerint egy jelszónak legalább egy számjegyet, illetve egy speciális karaktert kell tartalmaznia. Egy plusz számjegy hozzáadása, ahol egy számjegy tíz lehetséges értéket vehet fel, elméletben alig 3,3 bittel növeli az entrópiát. A gyakorlatban azonban jellemzően kevésbé, hiszen egy kötelezően megadandó számjegy esetén a legtöbben ugyanis az 1-est fogják megadni, innentől pedig a számjegy megjósolhatóvá válik. A speciális karakterek esetén a helyzet jobb kellene legyen, hiszen belőlük jócskán több van (32), mint számjegyekből (10) vagy akár az angol ábécé betűiből (26). Így elméletben az entrópiát is jobban (5 bit) növelik – de csak elméletben, hiszen a gyakorlatban a speciális karakterek jelentékeny részét nem feltétlenül ismerik a felhasználók, és ha mégis, a mobil és asztali környezet billentyűzeteinek eltérései miatt a speciális karakterek többségének használata roppant kényelmetlen.
Marad tehát az a gyakorta alkalmazott megoldás: ki-ki kiválaszt magának egy konkrét speciális karaktert, amit aztán minden olyan jelszavában használ, ahol ezt megkövetelik, jellemzően annak végére illesztve azt. Hamar kiderül tehát, hogy mi a különbség a szabályzat elmélete és gyakorlata között: elméletileg semmi.
Az emberi memória a biztonság súlyos korlátja
A jelszavak gyakori cseréje elméletben szintén növeli a biztonságot. Ha azonban megengedjük egyes részeinek ismétlődését, akkor tulajdonképpen nem sokban tér el a helyzetünk az előzőtől, hiszen a jelszóban megkövetelt számjegy jó eséllyel először az 1 lesz, majd az első kikényszerített jelszócsere után a 2 és így tovább.
Ha ennyi könnyítést sem engedünk a felhasználóinknak, akkor két eset kínálkozik. Az egyik, egyébként a kevésbé valószínű eshetőség, hogy a felhasználóink kiváló jelszóalkotási stratégia, illetve memória birtokában minden kikényszerített csere esetén teljesen új jelszót találnak ki. A másik lehetőség, hogy kitalálnak egy olyan stratégiát, amit az ellenőrzés nem fed, vagy nemes egyszerűséggel leírják a jelszót. Előbbi esetben félő, hogy a jelszavak megtippelésével, feltörésével foglalkozó szoftverek jobban lefedik a felhasználói stratégiákat, mint az ellenőrző szoftverek, amik elkerülni hivatottak az ilyen trükköket, vagyis hosszabb távon egyre kevésbé biztonságok jelszavak lesznek a rendszerünkben. Utóbbi esetben, ha a jelszó maga remek is, biztonsága annyi, mint annak a helynek (pl.: cetli a monitoron) a biztonsága, ahová azt leírtuk.
Annak demonstrálására, hogy mennyire nem szükségszerű, hogy az összetettebb jelszavak egyúttal biztonságosabbak is, szemléletes például szolgál a CVC és a PIN kód biztonságosságának viszonya. Előbbi egy 3 számjegyből álló kód, melyet a bankkártyánk hátoldalán találhatunk, és az online vásárlások során a kártya jogos felhasználásának bizonyítására szolgál. A PIN ugyanezt a célt szolgálja nem online használat esetén, annyi különbséggel, hogy nem 3, hanem 4 számjegyből áll. Mivel a hosszabb kód biztonságosabb, a PIN kódnak nagyobb biztonságot kellene nyújtania, mint a CVC-nek. Ez elméletben igaz is, viszont a gyakorlatban óriási különbség, hogy a PIN kód megváltoztatható, míg a CVC nem. Vagyis a CVC kód esetében az entrópia a gyakorlatban is az elméleti maximum (10 bit) lesz, de az PIN kód esetén a felhasználó ezt képes csökkenteni, amit rendre meg is tesz.
A 4 számjegy ugyanis nagyon csábít arra, hogy valamilyen dátumot (az évszám, hónap és napszám), általában valamilyen könnyen megjegyezhető, hozzánk jól köthető esemény időpontját használjuk PIN kód gyanánt. Ezekből egyébiránt nincs túl sok: saját és családtagjaink születésnapja és névnapja, nevezetes évfordulók stb. Leggyakrabban ebből az 10-20 dátumból választunk, vagyis az elméleti entrópia (13,3 bit) az előbbiek okán radikálisan, 4-5 bitre csökken. Eljutunk tehát oda, hogy egy elméletileg magasabb biztonságú módszer a gyakorlatban mégsem az. A névnap dátuma a kártyabitokos nevének ismeretében adott, a születésnapok és évfordulók dátumai a Facebook oldalak visszagörgetésével, a "mi az indián neved" jellegű adathalász alkalmazásokkal, illetve nyílt adatforrások felhasználásával (OSINT) meglehetősen nagy hatékonysággal deríthetők ki. Fentiek után talán nem meglepő, hogy a bankok erősen korlátozzák, hogy hányszor lehet próbálkozni egy CVC vagy PIN kóddal.
Cikkem második részében a kényelem és a biztonság viszonyával foglalkozom. Maradjanak velünk!
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ó.
Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak