Kategória: Informatika

Miért is használunk jelszókezelőt?

Többen érvelnek azzal, hogy nekik van már egy nagyon jól bevált, akár több mint 16 karakterből álló, kisbetűt, nagybetűt, még sepciális karaktert is tartalmazó jelszava, azt használja mindenütt, neki nincs szüksége jelszókezelőre…
Rendben – szoktam mondani erre -, tegyük fel, hogy a párunknak kinéztünk a „Mancika Webshop” oldalon egy ajándékot, amit megrendeltünk neki. Mint ma már minden webshop oldalon, itt is kötelező volt fiókot regisztrálni (sicc) , meg is tettük a szuper biztonságos kis jelszavunkkal. Majd kiderül (jobb esetben), hogy az adott oldalt feltörték és a felhasználói jelszavak kompromittálódtak, azok nem is titkosítva voltak tárolva (sicc)…
Akkor most hány helyen kell cserélnünk a szuperbiztonságos jelszavunkat!? Vezettünk erről egyáltalán nyilvántartást!?

Erre szokott jönni még a válasz, hogy a „nem fontos helyekre” van egy másik egyszerűbb jelszavam…
Egyrészről rendben, de akkor hány „nem fontos helyen” kell jelszót cserélnünk?
Másrészről a „fontos” helyeken is történt már incidens…
Harmadrészt a jelszavunk kikerülhet egy sikeres phising támadás által, vagy egy kompromittálódott eszközről is, stb…

Végül utolsó kapaszkodóként szokott jönni, hogy na jó, de nekem kétfaktoros azonosításom van!
Valóban, ez már egy nagy előrelépés, gratulálok! Néhány gondolatébresztő kérdés azért ebben az esetben is felmerül:

• Mit használtál második faktornak?
  • E-mail?
    • Ott is van 2FA?
    • Ott is ugyan az a jelszavad!?
  • Authy, hogy több eszközön is kéznél legyen?
    • Az Authy jelszava is ugyan ez?
  • Milyen alternatív bejelentkezésed van, ha elérhetetlen az elsődleges 2FA?
    • Ott sem jelent problémát ha kiderült a jelszavad?
  • Ha kompromittálódott a jelszavad, akkor ez most szerinted továbbra is 2FA?

A fentieket még lehetne persze tovább sorolni, azonban remélem már ennyiből is látszik, hogy valamilyen jelszókezelőre szükségünk van a mai világban.

Ok, jelszókezelőt, na de mit?

Elsőre adódik, hogy használjuk a böngészőnkbe épített jelszókezelőt, hiszen túlnyomórészt valamilyen webes felületet használunk már majdnem mindenütt. Alapvetően ezzel már nagyot léphetünk előre, ugyanakkor jellemzően ezen megoldásoknál a kényelem volt az elsődleges szempont, nem az IT biztonsági megfontolások.
A böngészőkben tárolt jelszavak egyrészt jellemzően viszonylag könnyedén visszanyerhetők, másrészről ugyan vannak megoldások, hogy ezek szinkronizálódjanak a többi eszközünkkel, ezek implementációja, illetve felhasználhatósága nem feltétlenül zökkenőmentes…

Elérhetőek az operációs rendszerbe integrált megoldások is. Az IT biztonsági megfontolások itt már nagyobb hangsúlyt kapnak, ugyanakkor ezek jellemzően az adott platformhoz kötnek, illetve nem támogatnak ezek sem pl. csoportos jelszókezelést, ami nem csak munkánál, de a családban is sokszor jól jön, vagy különböző jelentéseket, stb.

Vannak a több platformra is elérhető „offline” jelszókezelők, az egyik legnépszerűbb a KeePass, illetve léteznek ennek különböző, akár felhő tárolást is implementáló megoldásai is. Itt a jelszavak gyakorlatilag egy titkosított fájlban vannak tárolva, mely állományt meg tudunk osztani másokkal, a jelszó ismeretében pedig láthatjuk is a benne tárolt jelszavakat.
A kezelése jellemzően vágólapozással tud történni, azonban mobil eszközön már macerásabb a használata, illetve ha kompromittálódik, a benne tárolt jelszavak lecserélését nem nagyon támogatja automatizmusokkal.

LastPass

Az egyik legnagyobb kifejezetten jelszókezelésre készült platform. Magam is sok-sok éven át használtam, nem csak én, hanem a Family előfizetéssel a család is. Gyakorlatilag amikor megoldást kerestem a jelszókezelésre, nem is nagyon találtam alternatíváját, 2015 -ben pedig megvette a magyar kötődésű LogMeIn (ma már GoTo), ami kapcsán csak még szimpatikusabb is lett.
Aztán 2021. decemberében önállósult újra, mondván, hogy még hatékonyabban tudjon fejlődni. Lehet itt ment félre valami, nem tudom, mindenesetre az elmúlt időkben lassan vezető hírré váltak a LastPass -t érintő incidensek.
Alapjában véve ezzel még nem is feltétlenül lenne gond, hiszen sejthető, hogy egy erre specializálódott vezető megoldásszállító a támadók célkeresztjében van, ugyanakkor a napvilágra került információktól, az incidensek részleteitől, valamint azok kezelésétől a hátamon felállt a szőr, így 2023. változást hozott nálam.

Bitwarden

Nem titok, erre tértem át, nálam sokat nyomott a latba, hogy Open Source. Nem csak azért, mert nyílt forráskód párti vagyok, hanem azért is mert úgy gondolom ez is hozzátesz a biztonságához.
Tudom, sokakban most felmerül, hogy a nyílt forráskódú szoftver az sokkal kevésbé biztonságos, én meg pont az ellenkezőjét állítom. Azért, mert így van. 🙂
Véleményem szerint ez egy banális tévedés, általánosságban véve a nyílt forráskódú rendszer igen is sokkal biztonságosabb tud lenni!
Anélkül, hogy nagyon belemennék a részletekbe (majd lehet erről is írok egy bejegyzést egyszer) azért gondolom ezt így, mert valóban, ha Pistike ír egy programot és közzéteszi a kódját, abban sokkal könnyebben felfedezhetünk a forráskódból a hibákat, mintha nem ismernénk azt, ugyanakkor egy nagy rendszernél ez pont az ellenkezőjére fordul át. Sokkal többen nézik a forráskódot, hamarabb kiderülnek a hibák, nem nagyon lehet eltusolni, stb…

Visszatérve a Bitwarden -re, a váltásnál a másik vetélytársa nálam a 1Password volt. A váltáskor ráadásul a security megoldások a 1Password felé tolták a súlyt, végül a Bitwarden Open Source volta, az árazása, (valamint a megelőlegezett bizalom, hogy a döntéskor gyengébbnek vélt biztonság hamarosan itt is változik) a Bitwarden felé vitt, azzal a megkötéssel, hogy ha nem jön be, majd megyek tovább…

Jó jó, de mire mondom, hogy a gyengébbnek vélt biztonság, amikor pont a biztonságról papolok? Az alkalmazott titkosításra, pontosabban a password hashing -re.

PBKDF2

PBKDF2, vagyis Password-Based Key Derivation Function 2. Van még kérdés? 🙂
Nem kell megijedni, az alapelve egyszerű.

Kezdjük onnan, hogy amikor egy jelszót ellenőrzünk, gyakorlatilag valamilyen algoritmus mentén elkódoljuk (hash), és azt ellenőrizzük, hogy az megegyezik e a tárolt adattal. Ez az algoritmus egy olyan matematikai eljárás, ami kvázi egyirányú, tehát az eredményéből a forrást nem (legalábbis belátható időn belül nem) tudjuk visszafejteni.
Viszont ha rendelkezünk a titkosított jelszóval, akkor már tudjuk próbálgatni, hogy az adott jelszóból előáll e ugyanaz a titkosított jelszó. Ezt hívják brute force módszernek.
A technika fejlődésével, pláne a GPU -k, vagyis videokártyák térnyerésének (részben köszönhetően a videojátékoknak, valamint bitcoin bányászatnak is) ezek a próbálkozások viszonylag gyorsan végrehajthatók.
Ezért kitalálták, hogy a kódolt jelszót még iterálják több lépésben, így a próbálkozáshoz szükséges idő megnő.
A PBKDF2 az egyik legelterjedtebb eljárás erre. Ezt alkalmazva megfelelő iterációt követően a másodpercenként több százezer próbálkozás lecsökkenthető több tízezerre, vagy még kevesebbre. Gyakorlatilag kellően hosszú jelszó esetén ellehetetleníti a brute force jellegű próbálkozásokat. Az ismert jelszó ellenőrzésénél ugyanakkor továbbra is egyszer kell csak futtatni az algoritmust és az iterációkat, ami még így is nagyon rövid idő alatt elvégezhető.
Ha szeretnénk dollárosítva látni, hogy körülbelül mennyibe kerülne egy-egy jelszót próbálkozással feltörni, a https://support.1password.com/pbkdf2/ oldalon megnézhetjük.

Amiért írtam, hogy az átálláskor a gyengébb volt a Bitwarden a 1Password -nél, az egyrészről az, hogy a 1Password 650.000 iterációt végez, másrészről még egy titkos kulccsal is kombinálja azt, ami csak a kliens eszközökön van jelen. (Így ha kikerül egy állomány, a jelszó önmagában kevés.)
Ezzel szemben a Bitwarden 200.001 iterációt használ „csak”. Azért az idézőjel, mert a LastPass 100.100 -at használt, így ahhoz képest ez is előrelépés.
A teljesség kedvéért meg kell jegyezni, hogy itt is volt egy kis „huncutság”, a 200.001 iteráció 100.000 szerver oldali és 100.001 kliens oldali iterációból jött össze, a mester jelszó iterációja így csak 100.000 volt, gyakorlatilag ugyan annyi, mint a LastPass esetében is. (sicc)
További nem elhanyagolható probléma az, hogy az OWASP (Open Worldwide Application Security Project) ajánlás ma 600.000 iteráció a PBKDF2 esetében…

Szerencsé(m)re február közepe óta a Bitwarden is megemelte és alapértelmezetten már 600.001 iterációt használ, továbbá paraméterezhetővé is tette, hogy kliens oldalon hányszor szeretnénk iterálni. Így akár 650.000 -re is állíthatjuk mint a 1Password, de akár még feljebb is mehetünk, ha szeretnénk. Nyilván ez kihat a teljesítményre, de ha nem régi hardverekkel dolgozunk, nem nagyon vesszük észre a változtatást. (Persze ésszerű keretek között maradva. 🙂 )

Fontos, hogy ha 2023. február előtt hoztuk létre a fiókunkat, akkor automatikusan nem történik meg az iteráció emelése, azt nekünk kell megtenni, a webes felületen belépve! (Account Settings / Security / Keys)

Sőt mi több, ezen túlmenően a Bitwarden ezzel egyidőben elérhetővé tette az Argon2id algoritmust is!

Argon2

Az argon2 nyerte a 2015. évi Password Hashing Competition -t, az Argon2id ennek egy hybrid változata, amit a kombinációja az adatfüggő és adatfüggetlen memória elérést (data-depending, data-independent memory accesses).
Az Argon2i ellenállóbb a side-channel cache timing támadásokkal szemben, az Argon2d pedig a GPU alapú támadásokkal szemben.
Az Argon2 szemben az egyéb algoritmusokkal 3 paramétert használ, egy memória méretet (m), egy iteráció számot (t), valamint egy párhuzamossági számot (p).
Az alapértelmezett a Bitwarden esetében a jelenlegi OWASP ajánlás felett van:
64MiB memória, 3 iteráció, 4 szálon.
(Bővebben a Bitwarden által használt titkosításról: https://bitwarden.com/help/what-encryption-is-used/ )

Akkor most PBKDF2 vagy Argon2? És milyen paraméterekkel?

Az aktuális OWASP ajánlást itt találjuk: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
A jelenlegi Bitwarden alapértelmezések mind teljesítik, vagy fölötte vannak az ajánlásnak, néhanapján azért érdemes lehet ránézni az ajánlásra és a beállításainkra.
Ha szeretnénk megfelelni a NIST ajánlásnak, vagy fontos a FIPS-140 szerinti működés, akkor maradhatunk PBKDF2 -n, a megfelelő iteráció alkalmazása mellett.
Ha gyorsabban szeretnénk haladni a korral, használhatjuk már most az Argon2 -t is, szintén az ajánlott beállítások figyelembevétele mellett.

Ok, átálltam a Bitwarden -re (vagy másik jelszókezelőre), akkor most biztonságban vagyok, hátradőlhetek?

Természetesen nem! 🙂
Egyrészről fontos, hogy időnként a szuperbiztonságosnak tituált, már csak és kizárólag a jelszókezelőnkben használt master jelszavunkat is időről időre cseréljük le. Hogy miért? Mint a hash algoritmusoknál is láthattad, az ajánlás időről időre változik, ahogy a technika fejlődik, úgy az algoritmusok is avulnak el, a paramétereiket is emelni kell.
Ha egy korábbi backup kikerül, és az abban alkalmazott algoritmus már gyenge, vagy az akkor használt jelszavunk kikerül, akkor az összes jelszavunk kompromittálódott!

Akkor most hiába az egész?
Nem! Csak tudjuk, hogy dolgunk van a jelszavainkkal.
Ezen jelszókezelő rendszerek mind támogatják a jelszócseréket automatizmusokkal (bár meg kell hagyjam ebben a LastPass erősebb volt mint a Bitwarden), jelentéseket tudnak adni arról, hogy valamelyik jelszavunk szerepel e valamelyik nyilvánosságra került adatbázisban, illetve azokat is legyűjthetjük, hogy melyik jelszavunkat mikor cseréltük le utoljára (bár a Bitwarden -ben ezt pont nem találtam meg, remélem csak nem kerestem eléggé), de a gyenge jelszavainkat is tudja listázni, illetve azon nem biztonságosnak nyilvánított web oldalakról is adnak listát, ahol fiókunk van.

Ajánlások a biztonságos jelszókezeléshez

• Cseréljünk a jelszókezelőnk mester jelszavát legalább évente!
  A jelszó legyen kellően hosszú, legyen legalább 16 karakter, tartalmazzon kis és nagy betűket, valamint speciális karaktereket is.
• Legyen kötelező legalább a jelszókezelőnkhöz a 2FA.
• A jelszavainkat csoportosítsuk kritikusságuk szerint mappákba, ennek megfelelően szánjunk rá időt, és generáljunk új jelszavakat.
• Mindenhol használjunk más jelszót, a jelszavainkat ha más nem indokolja generáljuk, legyen legalább 16 karakter, tartalmazzon kis és nagy betűket, valamint speciális karaktereket is.
• Legalább évente gyűjtsük le a jelszókezelőben elérhető jelentéseket, és annak eredményétől függően tegyük meg a szükséges lépéseket.
• Legalább évente, illetve a tömeges jelszócseréket követően végezzünk biztonsági mentést!
  A mentést tároljuk biztos helyen, a kornak megfelelő titkosítás alkalmazásával! Az új mentést követően a régit semmisítsük meg! (Emlékezz amit korábban írtam, lehet, hogy azon mentésnél alkalmazott titkosítás már nem megbízható…)