Zobrazit příspěvky
5581
Vývoj / Re:Easy password a html5, sifrovanie/security
« kdy: 27. 11. 2013, 22:24:38 »
Přesně tímhle naivním přístupem k bezpečnosti vznikají systémy, které uživatele neskutečně otravují a pro útočníka jsou prakticky nezabezpečené.
Například to heslo. Heslo můžete použít v případě, lze zjistit jen informaci ano/ne (heslo je správně/špatně) a neexistuje nějaký boční kanál, kterým by mohl útočník získat nějaké další informace. Pak je heslo tak silné, jak dlouho by odolávalo útoku hrubou silou (zkoušení jednotlivých možností -- samozřejmě s využitím heuristik typu nejprve zkusím často používaná hesla, známá slova apod.). Pokud budete mít kilobajty a více dat a chtěl byste je zašifrovat obyčejným XORem, bude vám i to dvousetznakové heslo k ničemu, protože útočník může využít bočních informačních kanálů jako třeba různé opakující se vzory "prosvítající" i ze zašifrovaného textu.
Heslo tedy můžete použít třeba pro přihlášení k vzdálenému systému (který útočníkovi odpoví přihlášen/nepřihlášen a žádnou jinou informaci ze systému nedostane), nebo třeba k zašifrování šifrovacího klíče (který je sám o sobě náhodný, takže po rozšifrování heslem útočník neví, zda má správný klíč nebo jen náhodné znaky, a dozví se to teprve po pokusu rozšifrovat tím klíčem šifrovaná data).
Podle toho, kolik pokusů o uhádnutí hesla může útočník udělat za jednotku času pak musíte nastavit požadovanou délku hesla. Dnešní procesory jsou taktovány v jednotkách GHz, buďme optimisté a počítejme 10 GHz, 10 jádrový procesor a ověření hesla na jeden takt procesoru. Takový procesor by tedy dokázal za jednu sekundu ověřit 10^10 hesel. Když budeme brát v úvahu jen číselná hesla, uhodl by takové heslo průměrně za půl vteřiny, nejdéle za vteřinu. Když místo číslic použijete jen malá písmena anglické abecedy, bude průměrný čas na rozlousknutí skoro dvě hodiny; když použijete malá písmena, velká písmena a číslice, bude to přes rok.
Zatím měl útočník k dispozici jeden takový procesor. Předpokládejme, že jeden takový procesor má každý obyvatel Země, a útočník je všechny ovládne, takže těch procesorů má 10 miliard. Prodloužíme to číselné heslo na 20 číslic, a útočníkovi to zase bude trvat průměrně půl sekundy. Nebo použijeme místo 20místného PINu 12místné heslo z malých a velkých písmen anglické abecedy a číslic, to je silnější než ten 20místný PIN. Když místo toho 20místného PINu použijeme 25místný, bude to trvat půl dne, u 30místného 150 let, u 40místného je to přes bilion let, což je poněkud déle, než trvá současný vesmír. Při použití malých a velkých písmen a číslic se při použití 21 znaků dostanete někam na polovinu odhadovaného současného stáří vesmíru.
Na louskání 200znakového hesla byste tedy potřeboval celkem dost paralelních vesmírů.
A ta vaše navržená řešení? Mapování ze znaku nebo bodu na řetězec útočník zná a děje se v konstantním čase. Můžeme si ten výše uvedený vytuněný procesor rozšířit o koprocesor, který bude tohle mapování provádět paralelně s hlavním procesorem také na jeden takt. Takže zadáte Xmístné heslo, koprocesor ho v jednom taktu převede na vaše dvousetznakové heslo a hlavní procesor v témže taktu zjistí, zda je to heslo správné nebo chybné. takže počet vyzkoušených hesel za sekundu odpovídá stále tomu původnímu krátkému heslu, ta šaráda s prodlužováním na 200 znaků na to nemá vůbec žádný vliv. Vliv by měla, pokud by to mapování trvalo dostatečně dlouho, a prodlužovalo tedy celkový čas na ověření jednoho hesla. Například byste to heslo tisíckrát zahashoval nějakou pomalejší hashovací funkcí -- takovéhle pokusy některé systémy opravdu dělají. Má to dvě nevýhody. Ta menší je, že současné běžně používané hashovací funkce k tomuhle pokud vím nebyly navrženy, takže nikdo neví, zda je takovéhle použití neoslabuje. Nezapomeňte, že od druhého kroku dále počítáte hash z hashe, tedy z řetězce pevně dané délky. Čím déle budete hashovat, tím pravděpodobnější je, že narazíte na hash, který jste už jednou spočítal, a od té doby už se budou hashe už jen pravidelně opakovat. Ta větší nevýhoda je, že aby to mělo nějaký smysl, musíte ten čas prodloužit znatelně -- ale tu samou dobu bude muset čekat i uživatel, který zadá správné heslo. Výše jsem počítal s ověřením hesla na jeden takt procesoru. Když se vám to tím mapováním podaří prodloužit na jednu sekundu, je to stejné, jako byste k tomu číselnému PINu přidal 10 číslic. Ve skutečnosti to bude mnohem méně, protože dnešní procesory jsou řádově pomalejší, než to, co jsem uvedl nahoře -- takže při použití hesla z písmen a číslic dostanete to samé zlepšení přidáním odhadem dvou až třech znaků hesla.
Při navrhování zabezpečení přestaňte přemýšlet o klíčích, heslech a jiných termínech, pod kterými si nic nepředstavíte. Místo toho si zkuste představit, proti jakému druhu útoku má to vaše zabezpečení chránit a jakým způsobem by ho bylo možné obejít. Na pokročilejší věci jako frekvenční analýza zašifrovaného textu takhle nepřijdete, ale aspoň si uvědomíte třeba co přesně znamená délka hesla (ve skutečnosti jde jen o počet možných kombinací) a jaký význam má pro zabezpečení (prodloužení hesla o pár znaků prodlužuje dobu nutnou pro útok hrubou silou ze sekund na hodiny, ze dní na desetiletí).
Například to heslo. Heslo můžete použít v případě, lze zjistit jen informaci ano/ne (heslo je správně/špatně) a neexistuje nějaký boční kanál, kterým by mohl útočník získat nějaké další informace. Pak je heslo tak silné, jak dlouho by odolávalo útoku hrubou silou (zkoušení jednotlivých možností -- samozřejmě s využitím heuristik typu nejprve zkusím často používaná hesla, známá slova apod.). Pokud budete mít kilobajty a více dat a chtěl byste je zašifrovat obyčejným XORem, bude vám i to dvousetznakové heslo k ničemu, protože útočník může využít bočních informačních kanálů jako třeba různé opakující se vzory "prosvítající" i ze zašifrovaného textu.
Heslo tedy můžete použít třeba pro přihlášení k vzdálenému systému (který útočníkovi odpoví přihlášen/nepřihlášen a žádnou jinou informaci ze systému nedostane), nebo třeba k zašifrování šifrovacího klíče (který je sám o sobě náhodný, takže po rozšifrování heslem útočník neví, zda má správný klíč nebo jen náhodné znaky, a dozví se to teprve po pokusu rozšifrovat tím klíčem šifrovaná data).
Podle toho, kolik pokusů o uhádnutí hesla může útočník udělat za jednotku času pak musíte nastavit požadovanou délku hesla. Dnešní procesory jsou taktovány v jednotkách GHz, buďme optimisté a počítejme 10 GHz, 10 jádrový procesor a ověření hesla na jeden takt procesoru. Takový procesor by tedy dokázal za jednu sekundu ověřit 10^10 hesel. Když budeme brát v úvahu jen číselná hesla, uhodl by takové heslo průměrně za půl vteřiny, nejdéle za vteřinu. Když místo číslic použijete jen malá písmena anglické abecedy, bude průměrný čas na rozlousknutí skoro dvě hodiny; když použijete malá písmena, velká písmena a číslice, bude to přes rok.
Zatím měl útočník k dispozici jeden takový procesor. Předpokládejme, že jeden takový procesor má každý obyvatel Země, a útočník je všechny ovládne, takže těch procesorů má 10 miliard. Prodloužíme to číselné heslo na 20 číslic, a útočníkovi to zase bude trvat průměrně půl sekundy. Nebo použijeme místo 20místného PINu 12místné heslo z malých a velkých písmen anglické abecedy a číslic, to je silnější než ten 20místný PIN. Když místo toho 20místného PINu použijeme 25místný, bude to trvat půl dne, u 30místného 150 let, u 40místného je to přes bilion let, což je poněkud déle, než trvá současný vesmír. Při použití malých a velkých písmen a číslic se při použití 21 znaků dostanete někam na polovinu odhadovaného současného stáří vesmíru.
Na louskání 200znakového hesla byste tedy potřeboval celkem dost paralelních vesmírů.
A ta vaše navržená řešení? Mapování ze znaku nebo bodu na řetězec útočník zná a děje se v konstantním čase. Můžeme si ten výše uvedený vytuněný procesor rozšířit o koprocesor, který bude tohle mapování provádět paralelně s hlavním procesorem také na jeden takt. Takže zadáte Xmístné heslo, koprocesor ho v jednom taktu převede na vaše dvousetznakové heslo a hlavní procesor v témže taktu zjistí, zda je to heslo správné nebo chybné. takže počet vyzkoušených hesel za sekundu odpovídá stále tomu původnímu krátkému heslu, ta šaráda s prodlužováním na 200 znaků na to nemá vůbec žádný vliv. Vliv by měla, pokud by to mapování trvalo dostatečně dlouho, a prodlužovalo tedy celkový čas na ověření jednoho hesla. Například byste to heslo tisíckrát zahashoval nějakou pomalejší hashovací funkcí -- takovéhle pokusy některé systémy opravdu dělají. Má to dvě nevýhody. Ta menší je, že současné běžně používané hashovací funkce k tomuhle pokud vím nebyly navrženy, takže nikdo neví, zda je takovéhle použití neoslabuje. Nezapomeňte, že od druhého kroku dále počítáte hash z hashe, tedy z řetězce pevně dané délky. Čím déle budete hashovat, tím pravděpodobnější je, že narazíte na hash, který jste už jednou spočítal, a od té doby už se budou hashe už jen pravidelně opakovat. Ta větší nevýhoda je, že aby to mělo nějaký smysl, musíte ten čas prodloužit znatelně -- ale tu samou dobu bude muset čekat i uživatel, který zadá správné heslo. Výše jsem počítal s ověřením hesla na jeden takt procesoru. Když se vám to tím mapováním podaří prodloužit na jednu sekundu, je to stejné, jako byste k tomu číselnému PINu přidal 10 číslic. Ve skutečnosti to bude mnohem méně, protože dnešní procesory jsou řádově pomalejší, než to, co jsem uvedl nahoře -- takže při použití hesla z písmen a číslic dostanete to samé zlepšení přidáním odhadem dvou až třech znaků hesla.
Při navrhování zabezpečení přestaňte přemýšlet o klíčích, heslech a jiných termínech, pod kterými si nic nepředstavíte. Místo toho si zkuste představit, proti jakému druhu útoku má to vaše zabezpečení chránit a jakým způsobem by ho bylo možné obejít. Na pokročilejší věci jako frekvenční analýza zašifrovaného textu takhle nepřijdete, ale aspoň si uvědomíte třeba co přesně znamená délka hesla (ve skutečnosti jde jen o počet možných kombinací) a jaký význam má pro zabezpečení (prodloužení hesla o pár znaků prodlužuje dobu nutnou pro útok hrubou silou ze sekund na hodiny, ze dní na desetiletí).
