A kriptovaluta-felhasználók gyakran feltételezik, hogy az elvesztett eszközök azért tűnnek el, mert a blokklánc technológia hibás. A valóságban azonban a veszteségek nagy része már sokkal korábban történik: újrahasznált jelszó, sikeres adathalász oldal, gyenge helyreállítási folyamat vagy rossz helyen tárolt seed phrase. Ezek elkerülhető hibák lennének – de csak akkor, ha egyértelműen szét tudjuk választani, hogy pontosan milyen típusú titkot védünk, és mi történik, ha az kiszivárog.
Sokan éppen itt rontják el. A jelszó és a seed phrase mindkettő „hozzáférési adat”, de nem ugyanazt a kockázatot hordozzák. Ha az exchange jelszavadat ellopják, még mindig van esélyed visszaállítani a fiókot erős második faktorral és ügyfélszolgálati folyamattal. Ha viszont a tárca seed phrase-e vagy privát kulcsa szivárog ki, a támadó azonnal el tudja mozdítani a pénzeket, és ezek a tranzakciók visszafordíthatatlanok.
A kriptobiztonság szempontjából érdemes két rétegben gondolkodni.
Az első réteg a fiókhozzáférés. Ide tartozik az exchange-bejelentkezésed, az email-fiókod, illetve minden olyan szolgáltatás, ahol a személyazonosság és a munkamenet biztonsága számít. A jó jelszóhasználat és az erős hitelesítés drasztikusan csökkentheti a kockázatot.
A második réteg az eszköz feletti kontroll. Ez az a hely, ahol a seed phrase-k és privát kulcsok találhatók. Aki ezeket birtokolja, azé a pénz. A legtöbb önálló tárca esetén nincs ügyfélszolgálat, nincs visszavonás, nincs elfelejtett jelszó funkció.
Amikor a felhasználók mindkét réteget ugyanúgy kezelik, rejtett egyedüli hibapontokat hoznak létre. Például amikor exchange jelszavakat, seed phrase-fotókat, helyreállító e-maileket és 2FA mentőkulcsokat gyengén védett felhasználói appokba töltenek, egyetlen biztonsági rés vezethet a teljes kompromittálódáshoz.
A legtöbb incidens mindig ugyanazt a mintát követi. Az eszköz változik, a működési hibák maradnak:
Ha jobban megnézzük, ezek inkább folyamat-, mint technikai hibák. A támadóknak nincs szükségük arra, hogy feltörjék a modern kriptográfiát, ha ki tudják használni a zavart, sürgetést vagy a kényelemből fakadó hibákat.
A jelszókezelő tökéletes olyan nehezen megjegyezhető és könnyen forgatható adatokhoz, mint az exchange bejelentkezés, API kulcsok, mentőkódok vagy helyreállítási folyamatokat leíró jegyzetek. Csoportmunkában ez a legbiztonságosabb módja az átadásoknak anélkül, hogy a nyers jelszavak chatben vagy emailben kerülnének megosztásra.
A seed phrase-ek és privát kulcsok viszont szigorúbb kezelést igényelnek. Hosszú távú tárolásra az offline megközelítés a legbiztonságosabb, dokumentált helyreállítási folyamattal és egyértelmű tulajdonosi szabályokkal párosulva. Vannak, akik még így is digitálisan tárolják ezeket a helyreállító információkat a kényelem kedvéért, de ez mindig egy tudatos és szigorúan kontrollált kockázati döntés kell legyen – nem automatikus szokás.
A gyakorlatban egy többrétegű megközelítés a legjobb: napi fiókjelszavakat erős MFA-val védett jelszókezelőben tároljunk, míg a nagy értékű helyreállító titkokat jobban elzárva, külön. A helyreállítási dokumentáció pedig legyen annyira világos, hogy stresszhelyzetben is végrehajtható legyen megbízható személyek által.
A kriptó adathalászat azért működik jól, mert a gyorsaságot, sürgetést és a visszafordíthatatlan következményeket vegyíti. A támadók tudják, hogy a felhasználók piaci mozgás esetén gyors lépésre vannak kondicionálva. Exchange értesítéseket, wallet frissítéseket vagy „biztonsági ellenőrzést” imitálnak, majd ráveszik az áldozatot a belépési adatok megadására vagy rosszvágyú tranzakció jóváhagyására.
A hatékony védekezés egyik alapszabálya: tekintsd a sürgetést kockázati jelzésnek – ne érvnek arra, hogy gyorsabban cselekedj! Ha üzenetben követelik, hogy „azonnal lépj” elkerülendő a felfüggesztést, zárolást vagy veszteséget, állj meg, és hiteles forrásból ellenőrizd a dolgot. Valódi biztonsági csapat soha nem fogja kérni a seed phrase-edet, és egyetlen legitim folyamat sem kéri, hogy ezt véletlenszerű oldalakon vagy support chatben írd be.
A jelszókezelőknek ezen a ponton is hasznát veheted: az automatikus kitöltés védő funkció is lehet. Ha a mentett jelszavad nem illik pontosan a domainhez, az a kényelmetlenség valójában egy hasznos figyelmeztetés.
Sokan sokat fektetnek a megelőzésbe, de alig törődnek a helyreállítással. Ez téves sorrend. A megelőzés egyszer biztosan csődöt mond, ekkor a helyreállítás minősége dönti el, hogy egy incidens csak apró fennakadás vagy végzetes veszteség lesz-e.
A helyreállítási tervezésnek konkrét kérdésekre kell választ adni már jóval a baj előtt: Melyik jelszó forog elsőként? Kinek van joga vészhelyzetben változtatni? Mely készülékek megbízhatók újraregisztrációra? Hol vannak a mentőkódok? Ki igazolja, hogy a helyreállított fiók valóban tiszta?
Ha ezekre nincs előre válasz, az emberek improvizálnak a lehető legrosszabb pillanatban. Ilyenkor történnek másodlagos hibák: rossz fiókot forgatnak először, kifelé felejtik az API kulcsokat vagy kompromittált végpontról állítanak vissza.
Egy jól alkalmazható, gyakorlati elv: minden kritikus fióknak legyen tulajdonosa, helyettes tulajdonosa és tesztelt helyreállítási útvonala. Cégeknél ennek a be- és kiléptetés részének kell lennie, nem kimondatlan „törzsi tudásnak”.
Nem kell komplett biztonsági program ahhoz, hogy azonnal javíts a helyzeten. Egy rövid, tudatos „hardening pass” már sokat segít:
Ezek a lépések nem garantálják a teljes védelmet, de a legtöbb hétköznapi támadási útvonalat jelentősen lezárják.
A legnagyobb kriptós biztonsági hiba nem az, hogy „rossz alkalmazást” használsz. Hanem az, ha nem választod szét a kényelmi titkokat a valódi tulajdonosi titkoktól. A jelszavakat legyen könnyű generálni, tárolni, forogtatni és biztonságosan megosztani egy megfelelő jelszókezelőben. A seed phrase-eket és privát kulcsokat viszont szigorúbban, dokumentált helyreállítással, elkülönítve kezeld.
Ha csapatot vezetsz, mindez még fontosabb. Az egyéni szokások gyorsan szervezeti kockázattá válnak. Egyértelmű titok-besorolási szabályzat, következetes hozzáférés-szabályozás és rendszeresen tesztelt helyreállítás sokkal több veszteséget előz meg, mint az utólagos sebtapasz megoldások.
További hasznos tanácsokat találsz a miért bizonytalan az SMS-alapú 2FA, hogyan védekezhetsz a credential stuffing ellen, illetve modern social engineering támadások témájú posztjainkban is.