Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Jores has a deprecated constructor in /www/it-joker.cz/it-joker.cz/includes/class.Jores.php on line 21

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; Database has a deprecated constructor in /www/it-joker.cz/it-joker.cz/includes/class.Database.php on line 5

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; JoresTemplate has a deprecated constructor in /www/it-joker.cz/it-joker.cz/includes/class.JoresTemplate.php on line 84

Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; JoresTemplate_plugin has a deprecated constructor in /www/it-joker.cz/it-joker.cz/includes/class.JoresTemplate.php on line 469
Zabezpečení hesla z pohledu programátora

„Ajťák“ Joker, osobní stránky

Nacházíte se v části webu: Hlavní stránka › Počítače, weby

Zabezpečení hesla z pohledu programátora

napsal Joker, 21.2.2009 19.49:14, naposledy upraveno 21.2.2009 20.29:04

Kdysi jsem tu napsal článek o zabezpečení hesla z pohledu uživatele. Volba silného hesla na straně uživatele je samozřejmě jen jedna část, to hlavní je na programátorovi. Tak nějak jsem předpokládal, že programuje-li někdo nějakou serioznější webovou aplikaci, alespoň nějaký pokus o zabezpečení vždy udělá. Byl jsem vyveden z omylu.

Protože jsem nenašel článek shrnující nějaké základy zabezpečení hesel pro programátory (když už nějaký je, obvykle rozebírá jednu konkrétní metodu), zkusím takový souhrn napsat sám.

Zaměřím se na hesla na webových stránkách. Nepůjde o nějaké objevné informace, spíš shrnutí základů. Předpokládejme, že máme webovou aplikaci, heslo se ukládá v nějakém úložišti (typicky databáze) odděleně od samotného kódu aplikace.

Typy útoků

Aby bylo možné zabezpečení webu plánovat, potřebujeme vědět, z jakých směrů je vlastně možné potenciální pokusy o narušení bezpečnosti očekávat. Podívejme se nyní zhruba na druhy útoků, jejich nebezpečnost a základní možnosti obrany. Důležitá je i náročnost útoku- čím je provedení útoku složitější, tím větší motivaci musí útočník mít, aby to vůbec zkoušel, respektive je méně pravděpodobné, že to vůbec někdo bude zkoušet.

Útok hrubou silou

Popis:
V nejprimitivnější variantě útočník prostě zadá cizí jméno a heslo si tipne. Pokročilejší varianta využívá robota, který prostě zkouší různá hesla (buď prostě všechny kombinace znaků, nebo má nějaký slovník, ze kterého hesla bere) a doufá, že se "trefí". 
Náročnost:
Minimální. Může to udělat prakticky každý
Nebezpečnost:
Závisí na tom, jaké si uživatel zvolil heslo. Tady přichází ke slovu minulý článek o bezpečnosti hesel z pohledu uživatele. V případě, kdy uživatel má silné heslo a útočník nemá indicie, jaké to heslo je, jsou útočníkovy naděje minimální. Při použití robota ale může nastat jiný problém, a sice že robot se bude zkoušet přihlašovat tak často, že zahltí server požadavky a ten pak nebude schopný reagovat na požadavky "lidských" uživatelů, tj. z pohledu uživatele to způsobí výpadek webu (takzvaný DoS útok)
Možnosti ochrany:
Tady je to z velké části na samotném uživateli. Programátor může udělat to, že bude nutit uživatele k volbě dostatečně silného hesla (na druhou stranu je třeba to vyvážit tak, aby to uživatele zbytečně neotravovalo). Dále je možné omezit maximální počet neúspěšných přihlášení za nějaký časový interval. Příklad: po deseti neúspěšných pokusech o přihlášení ke stejnému účtu se třeba na 15 minut zablokují další pokusy o přihlášení k danému účtu.

Prolomení hesla

Popis:
Útočník se pokusí získat záznam oběti z datového úložiště na serveru a potom z toho záznamu získat heslo.
Náročnost:
Závisí na návrhu aplikace. První problém útočníka je získat data o oběti ze serveru. To není snadné, ale často lze využít nějaké přehlédnuté chyby v aplikaci, případně jako v případě libimseti.cz získat kopii zálohy databáze. Druhý problém je ze získaných dat vytěžit informace, které by byly pro útok použitelné. S adekvátním zabezpečením aplikace to je velice obtížné.
Nebezpečnost:
Opět závisí na návrhu aplikace. Hodně aplikací vpodstatě spoléhá na to, že se k záznamům v databázi nikdo nepovolaný nedostane. V takovém případě už samotné přečtení databáze představuje vysoké bezpečnostní riziko. Při dobrém zabezpečení je ale nebezpečí nízké.
Možnosti ochrany:
Na možnosti ochrany proti tomuto útoku se podíváme dále v článku.

Odposlouchávání

Popis:
Útočník s pomocí speciálního software (tzv. sniffer) odposlouchává komunikaci na síti. Odchytí formulář odesílaný uživatelem na server a pokusí se z něj vydolovat heslo. 
Náročnost:
Hlavní náročnost tohoto útoku spočívá v tom, že odposlouchávat data lze jen v místech, přes která ta data proudí. Útočník musí proto získat k nějakému síťovému prvku mezi obětí a serverem takový přístup, aby mohl sledovat komunikaci protékající tím síťovým prvkem. Pokud oběť je v lokální síti postavené z hubů (které všechna data přeposílají všem připojeným počítačům), stačí útočníkovi být jen ve stejném segmentu lokální sítě jako oběť. Dále útočník potřebuje ještě zmíněný program- sniffer, ale ten se dá celkem snadno stáhnout z webu.
Nebezpečnost:
Vysoká, pokud aplikace není proti tomuto útoku chráněna.
Možnosti ochrany:
Použití šifrované komunikace (protokol https://) znemožní (respektive o mnoho řádů zesložití) odposlouchávání. Odposlechnutí hesla lze ale zabránit i bez šifrované komunikace, což rozebereme dále v článku.

Man in the middle

Popis:
Útočník se "postaví do cesty" mezi oběť a server tak, aby komunikace mezi obětí a serverem proudila přes něj. Následně pak může nejen číst, ale i modifikovat data, která posílá uživatel serveru nebo server uživateli. 
Náročnost:
Vysoká. Útočník musí získat přístup k síťovému prvku nebo počítači na cestě mezi obětí a serverem. Dále útok vyžaduje speciální software a určité znalosti. Při použití šifrované komunikace tento typ útoku prakticky není možný.
Nebezpečnost:
Vysoká. Pokud se útočníkovi už podaří dostat do pozice "man in the middle", je úspěch útoku téměř zaručen.
Možnosti ochrany:
Vpodstatě jediná účinná obrana proti man in the middle útoku je použití šifrované komunikace (protokolu https://)

Převzetí relace (session stealing)

Popis:
Útočník nějakým způsobem od oběti získá její ID relace, ve které má platné přihlášení na serveru. Následně tuto relaci začne vydávat za svou a tím převezme regulérní přihlášení oběti. 
Náročnost:
Střední až vyšší v případě, že aplikace není proti tomuto útoku chráněna. Útočník musí hlavně vylákat z oběti její ID relace (session ID). Pokud aplikace předává ID relace jako parametr v adrese stránky, nemusí to být tak velký problém- stačí přesvědčit oběť, aby třeba e-mailem poslala odkaz na nějakou stránku na příslušném webu... a součástí adresy bude i ID relace. Při dobrém návrhu aplikace je však tento útok téměř nemožný.
Nebezpečnost:
Při dobrém návrhu aplikace je nebezpečnost minimální.
Možnosti ochrany:
Nepředávat ID relace v adrese stránky. Spárování relace s údaji o uživateli (například IP adresa, použitý prohlížeč apod.) a odhlášení uživatele v případě, že se tyto údaje změní, také pomáhá výrazně omezit riziko tohoto útoku.

Získání kontroly nad aplikací

Popis:
Útočník nějakým způsobem získá možnost provést na serveru svůj vlastní kód (buď získá přímo přístup na FTP, nebo třeba přes script injection a podobně)
Náročnost:
Závisí na aplikaci, při dobrém návrhu aplikace by toto nemělo být možné. I u špatně navržené aplikace bývá ale často realizace tohoto útoku složitá (naštěstí).
Nebezpečnost:
Kritická. Samotné provedení tohoto útoku je mnohem horší bezpečnostní riziko, než případné získání cizího hesla.
Možnosti ochrany:
Tento bod tu je hlavně z důvodu, že podobný druh útoku často padne v diskusi ve chvíli, kdy už někdo navrhne dostatečně "neprůstřelné" zabezpečení hesla. Je potřeba si uvědomit, že samozřejmě každé zabezpečení je v nějakém kontextu. Ve chvíli, kdy někdo získá možnost ovlivňovat samotný kód aplikace, už čelíte mnohem vážnějšímu narušení bezpečnosti, než je prozrazení nějakého hesla. V tu chvíli už nemá smysl se bavit o zabezpečení hesel- hlavní úkol je zabezpečit aplikaci, aby k něčemu takovému nemohlo dojít. Ale to je na jiný článek. 

Tolik k tomu,z jakých směrů lze zhruba očekávat pokusy o neautorizovaný přístup k aplikaci. Na další stránce se podíváme na možné metody zabezpečení.

Přejít na stránku: [ 1 2 ]

[1] od: bohyn × (25.2.2009 17.40:58)
Ad soleni hashe: Sul se da kombinovat dynamicka a staticka treba "uz_jmeno@heslo" a ziskat tak vyhodu obojiho.

[2] od: df × (26.10.2009 13.23:55)
Musim vas zklamat. Https neni zadnou obranou proti MITM. Viz http://cs.wikipedia.org/wiki/Man_in_the_middle

[3] od: Joker ® (26.10.2009 16.51:46)
[2] Proč ne? Při zahájení HTTPS komunikace mám veřejný klíč protistrany, nejlépe ověřený nezávislým komunikačním kanálem. Útočník tedy bez znalosti soukromého klíče nedokáže předstírat druhou stranu komunikace, ani za běhu modifikovat data. Při použití dostatečně silného šifrování ideálně nedokáže ani v použitelném čase dešifrovat obsah komunikace.

[4] od: M2D HASH × (11.5.2010 5.26:16)
kurvaa

[5] od: Seith × (5.3.2011 12.39:50)
Ahoj, mám dotaz ohledně nutnosti použít AJAX a posílat minulou výzvu až po zadání hesla. Nevidím bezpečnostní rozdíl v tom, když dojde k odeslání minulé výzvy společně s tou "aktuální" při zobrazení formuláře. Je v tom nějaký zásadní rozdíl?

[6] od: </body> × (13.3.2011 15.51:27)
heh

Přidat nový komentář