Proč tak často dochází k únikům hesel?
V poslední době došlo k několika velkým únikům hashů hesel a k jejich následnému prolomení. Proč k tomu došlo? Dalo se tomu zabránit? Na tyto a další otázky se pokouší odpovědět tento rozhovor.
Většina provozovatelů webů buď spoléhá na to, že uživatelé budou používat bezpečná hesla a nebo jim je to úplně jedno. Pravda je taková, že uživatelé již po několik desítek let používají slabá hesla, která lze snadno uhádnout, a nic nenasvědčuje tomu, že by tomu mělo být do budoucna jinak. Kromě toho nelze očekávat, že by v dohledné době byla hesla zcela nahrazena nějakou jinou autentizační metodou. Musíme se tedy chtě nechtě smířit s tím, že hesla se budou i nadále v rámci autentizace používat a usilovat o minimalizaci rizik s tím spojených.
Chcete říci, že se za posledních několik desítek let v této oblasti vůbec nic nezměnilo?
Ano, pokud jde o autentizaci uživatele pomocí hesla, tak mohu naprosto odpovědně prohlásit, že se nezměnilo vůbec nic. Drtivá většina uživatelů stále používá slabá hesla, a ta jsou vzhledem k nevhodně implementované kryptografii úspěšně lámána. Za určitý posun lze vnímat snad jen jedině používání dvoufaktorové autentizace, především jednorázových hesel, generovaných stále častěji pomocí smartphonu, který plní roli tzv. SW tokenu, jenž sice není tak bezpečný jako HW token, ale významně snižuje riziko.
Nestačilo by ty aplikace nastavit tak, aby po uživateli vyžadovaly zadání komplexního hesla?
Ovšemže stačilo, problém není v tom, že bychom nedokázali kontrolovat, zda je heslo dostatečně silné, či nikoliv, ale v tom, že provozovatelům těchto webů jde především o to, aby se u nich uživatel zaregistroval a jejich službu aktivně používal. Firmy by mohly hesla zadané uživatelem rovnou kontrolovat proti heslům, která unikla na internet, ale to by se nikdo nezaregistroval. Kromě toho je autentizace dost často požadována i tam, kde to nemá moc smysl. Pokud chcete mít velké množství registrovaných uživatelů, nemůžete je odradit nějakými přísnými požadavky na délku a složitost hesla. Všimněte si, že i weby, které byly napadeny, a ze kterých hesla unikla, své nároky na délku a komplexitu hesla nezměnily. A ještě jedna věc, v okamžiku, kdy budete vyžadovat komplexní heslo, nebude moci nikdo použít passphrase. Pravda je, že ji skoro nikdo nepoužívá.
Dobře, a co ta dvoufaktorová autentizace? Mobil má dnes přeci již skoro každý, tak proč by právě on nemohl sloužit jako druhý faktor?
Jistěže mohl, třeba takový Google Authenticator je skvělá aplikace, ale zase je to o tom, že uživatele tento způsob autentizace prostě otravuje. Uživatelé mají prsty na klávesnici nebo na myši a nyní musí vytáhnout mobil, spustit tam nějakou aplikaci, vygenerovat kód, ten správně přečíst a přepsat. Kromě toho aby se uživatel mohl tímto způsobem autentizovat, musí si danou aplikaci nejprve stáhnout, nainstalovat, nakonfigurovat. To je moc úkonů, a navíc tady se nebavíme o přihlášení do internetového bankovnictví, ale do nějakých obyčejných webových aplikací. Narážíme zde opět na klasický problém bezpečnost x použitelnost x cena, protože i provozovatele webu tento způsob autentizace něco stojí.
Nespočívaly však nedávno medializované úniky hesel spíše v tom, že dané webové aplikace byly prostě děravé?
Ano, nejspíš tomu tak skutečně bylo. Webové aplikace dost často obsahují zranitelnosti, kterých je možno zneužít, v tomto případě byl nejspíš proveden SQL injection útok, ale to nemohu tvrdit, protože nejsem s těmito kauzami detailně obeznámen. Je možné, že DB s hesly unikly i úplně jiným způsobem. Je třeba si uvědomit, že i když bude aplikace vyvíjena s ohledem na doporučení, která uvádí OWASP a na bezpečnost bude kladen velký důraz, tak není možné se spolehnout na to, že se do DB, ve které jsou uložené hashe hesel nikdo nedostane. Vždy se může objevit nějaká zranitelnost nultého dne nebo může administrátor prostě udělat chybu. Vždy je třeba počítat s tím, že DB může být kompromitována a mít proto zavedena další bezpečnostní opatření.
Nebylo by řešením DB s hesly umístit na jiný server, který by nebyl z internetu dostupný?
Zcela určitě. Trochu mne překvapuje, že firmám s takovým rozpočtem nic neříká vertikální škálování a jsou schopny provozovat webový aplikační i databázový server na jedné vrstvě. V okamžiku, kdyby byly autentizační údaje umístěny na serveru, který není přístupný z internetu, měl by útočník výrazně ztížený útok. A jsem přesvědčen, že pokud byla vaše aplikace vyvinuta jako vícevrstvá, neměli byste mít problém takovou změnu provést.
Hesla prý byla prolomena především proto, že byla špatně implementována kryptografie a v jednom případě nebyla dokonce vůbec použita sůl.
Tohle je bohužel problém, který se týká většiny webů. To, že v jejich případě nedošlo k úniku hesel, je dáno čistě jen tím, že se na ně útočníci nezaměřili nebo tyto systémy neobsahovaly známou zranitelnost. Pokud jde o tu sůl, tak tu je vždy dobré použít, protože jak jsme si již řekli, na uživatele se nelze, pokud jde o použití silného hesla, v žádném případě spolehnout. Je zřejmé, že když pak dojde k úniku hashů a není použita sůl, mohou útočníci tato slabá hesla snadno prolomit pomocí rainbow tables.
Dobře, ale v okamžiku, kdy útočník získá celou DB, tak má přeci k dispozici i sůl a může si sestavit vlastní rainbow tables.
To opravdu může, a pokud by byla použita stejná sůl pro všechny uživatele dané služby, tak mu to nezabere ani moc času, ovšem v okamžiku, kdy byla pro každého uživatele použita jiná sůl, tak by musel generovat rainbow tables pro každého uživatele zvlášť, a to se mu prostě nevyplatí, to už může dané heslo rovnou lámat hrubou silou a také se to tak dělá, protože není vůbec žádný problém prolomit komplexní 7znakové osolené heslo, poněvadž délka a kvalita soli zde nehraje vůbec žádnou roli.
To by ale znamenalo, že uživatele, kteří budou nadále používat slabá hesla, nějaká sůl vůbec neochrání.
Přesně tak. A neochrání je mimo jiné i proto, že se používá špatná kryptografická funkce. Uvědomte si, že hashovací funkce byly vyvinuty proto, aby bylo možné z velkého objemu dat rychle vygenerovat otisk. To, že byly zpočátku používány i pro vytváření hashů z hesel nikomu nevadilo, ale tím jako roste výpočetní výkon, je stále jednodušší tato hesla lámat, a proto se nabízí otázka, zda místo klasických hashovacích funkcí jako je SHA nepoužívat raději jiné, proto tento účel mnohem vhodnější. Konkrétně takové, které umožňují key stretching.
Je možné jednoduše popsat jak takové algoritmy fungují?
Samozřejmě. Cílem těchto algoritmů nebo jejich implementací je maximálně zpomalit útočníka. To lze i pomocí klasických hashovacích funkcí jako je SHA, prostě se hashování provede několikrát, třeba tisíckrát a až ten poslední hash se uloží do DB. Když pak uživatel pošle svoje heslo, musí se opět tisíckrát zahashovat a pak porovnat s tím, které je uložené v DB. A odpovídající počet iterací musí provést i útočník, pokud chce takový hash lámat. Stanovení odpovídajícího počtu iterací je individuální a vždy musí být důkladně otestováno, jaký to bude mít dopad na výkon serveru. Uživatel nepozná, jestli autentizace trvá jednu sekundu nebo deset milisekund, ovšem útočníka to podstatně zpomalí. Už nemůže zkoušet několik set miliónů hesel za sekundu, ale podstatně méně. A nepomůže mu v tom ani CUDA ani spuštění tohoto výpočtu někde v cloudu. Jiným řešením je použít krátkou sůl, ale nikam ji neukládat a pak nechat server vyzkoušet všechny možnosti.
No jo, ale nemůže být právě skutečnost, že tento algoritmus vyžaduje více procesorového času zneužit k DoS útoku na daný server?
Může, a také proto se s implementací tohoto autentizačního schématu tak často nesetkáme. Opět se dostáváme k tomu, že firmy se více bojí toho, že by někdo mohl způsobit nedostupnost jejich služby, než že by útočník mohl prolomit hesla většiny jejich uživatelů. Na první pohled možná zvláštní, ale vysvětlení je opět velice prosté. Jestliže daná služba není funkční, firma utrpí ztrátu. Ovšem jestliže uniknou hesla, která útočník zpravidla nezmění, mohou uživatelé danou službu nadále používat. Některé odvážnější firmy, které do tohoto řešení šly, z obavy před DoS útokem nasadily CAPTCHA, ale to je bohužel z pohledu uživatele to nejhorší možné řešení.
A nedal by se tento náročný výpočet přesunout na klienta?
Dal, ale k čemu by to vedlo? Klient by serveru posílal jen hash a pokud by byla zcizena DB s hashi, nemusel by útočník hash lámat, prostě by ho jen poslal. Ne, tohle není ta správná cesta. Ovšem pokud vám jde o ten DoS útok, tak je zde jiná možnost, jak se mu bránit, a to požádat klienta, aby provedl nějakou práci, jedná se o tzv. Proof-Of-Work systém.
Štítky: autentizace, kryptografie, lámání hesel, rozhovor
K článku “Proč tak často dochází k únikům hesel?” se zde nenachází žádný komentář - buďte první.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.
