Easy password a HTML5

pdx

Easy password a HTML5
« kdy: 27. 11. 2013, 17:44:36 »
Ahoj,
rozmýšľal som nad tým ako čo najlepšie (z pohľadu užívateľa) vyriešiť zadávanie naozaj silného hesla/kľúča, ktorým by sa odšifrovala (predtým rovnakým heslom zašifrovaná) local storage.
Tam by boli uložené nastavenia, dáta. Inak by sa užívateľ musel stále on-line prihlasovať na server alebo by mal hocikto/hocijaká app  prístup k tým dátam. Išlo by o riešenie hlavne pre smartphony.

Aby to šifrovanie bolo silné musí byť aj heslo silné. Ideálne cez 200+ znakov. To si, ale nikto nebude pamäť ani sa ho nikomu nebude chcieť stále zadávať. Mohol by si ho uložiť do prehliadača, ale kto im už dnes verí ...

Napadli mi dve riešenia:
1, jednoduché heslo (min 4 znaky) a každý znak bude namapovaný na nejaký reťazec. Napr. nejaký SHA1 hash (napr. znak A bude SHA1("lorem") atď).
Takže výsledné heslo bude raťazec s min 4 SHA1 hashov - čo je už celkom dlhé heslo.

2, užívateľ pospája nejaké body na na poli 3x3 (bežné odomykanie na Androidoch) a každý bod bude reprezentovať nejaký reťazec, napr. SHA1 hash, ktoré sa spoja (viď 1,) a to bude heslo.

Ako bonus by sa by sa mohol samotný užívateľov vstup (to krátke hesielko, či postupnosť bodov - napr: 5, 6, 7) zahashovať a pridať k heslu.

Šifrovanie by bolo riešené externou JS knižnicou.
Cieľ je, aby užívateľ mal svoje dáta chránené. Samozrejme, tieto šifrované dáta by mohli byť uložené aj na servery, aby sa prípadne mohli synchronizovať s inými zariadeniami.

Otázka/y: je to dobrý nápad? Nemám tam niekde logickú chybu? Nie je to Security through obscurity? Boli by ste ochotní zadávať heslo, pri každom spustení app?

Dík
pdx
« Poslední změna: 28. 11. 2013, 11:07:44 od Petr Krčmář »


Jimm

Re:Easy password a html5, sifrovanie/security
« Odpověď #1 kdy: 27. 11. 2013, 18:06:18 »
Nějak ti asi nerozumím... Na řetězec by se to převádělo na klientu, nebo až na serveru? Pokud na klientu, je to odchytnutelné, pokud na serveru, stačí odeslat tu jednoduchou sekvenci... Jak to tak čtu, raději bych se na tvém místě do nějakého zabezpečování nepouštěl.

Jim

pdx

Re:Easy password a html5, sifrovanie/security
« Odpověď #2 kdy: 27. 11. 2013, 18:26:01 »
Bežalo by to na celé na klientovi, keďže tá app má fungovať aj off-line - čo je hlavný problém ako tie dáta zachovať max bezpečné.

Má to byť relatívne jednoduchá app (RSS reader), len prehliadače ukladajú local storage ako +/-plain text, tak to chcem pre dobro užívateľa zašifrovať.

Asi som to celé nejak blbo napísal :(
ale dík za odpoveď

JSH

Re:Easy password a html5, sifrovanie/security
« Odpověď #3 kdy: 27. 11. 2013, 20:40:51 »
Aby to šifrovanie bolo silné musí byť aj heslo silné. Ideálne cez 200+ znakov. To si, ale nikto nebude pamäť ani sa ho nikomu nebude chcieť stále zadávať. Mohol by si ho uložiť do prehliadača, ale kto im už dnes verí ...

Ježkovy oči, proč 200 znaků? AES používá stovky bitů a ne znaků.

Základní pravidlo je, že pokud je něco moc složité, nebo to prudí, pak to uživatelé obcházejí a bezpečnost jde do kopru.

Citace
1, jednoduché heslo (min 4 znaky) a každý znak bude namapovaný na nejaký reťazec. Napr. nejaký SHA1 hash (napr. znak A bude SHA1("lorem") atď).

Proč převádět znaky na řetězce a hasnovat, když stačí zahashovat ty 4 znaky přímo. Výsledný počet kombinací je pořád stejný. Pokud jsou vstupem 4 znaky, pak je jakýkoliv binec maximálně stejně dobrý jako čtyřznakové heslo.

Prostě je úplně jedno, co s tím uděláš. Slabé heslo nevylepšíš. A jakékoliv jednoznačné zobrazování jednotlivých znaků na cokoliv tam vůbec nemusí být.

Citace
2, užívateľ pospája nejaké body na na poli 3x3 (bežné odomykanie na Androidoch) a každý bod bude reprezentovať nejaký reťazec, napr. SHA1 hash, ktoré sa spoja (viď 1,) a to bude heslo.

To už má trochu lepší počet možných kombinací, ale zase by stačilo vzít indexy těch bodů. Všechno to hashování za tím může být dobré jen pro pálení cyklů procesoru, aby se zpomalilo bruteforce hledání.

Citace
Nie je to Security through obscurity?

Je. Pokud nerozumíš kryptografii a vymýšlíš něco vlastního, pak se pravděpodobnost, že děláš něco rozumného, limitně blíží nule.

Citace
Boli by ste ochotní zadávať heslo, pri každom spustení app?

Ne. Lokální data se chrání na úrovni operačního systému a šifrování disku.

Shrnutí :

Vybodni se na to. Pokud bude chtít uživatel zabezpečit ta lokální data pro případ, že by se mu k počítači někdo dostal, pak si zašifruje disk. Ty jako programátor aplikace mu nijak nepomůžeš. Jakýmkoliv šifrováním jen dáš laikům falešný pocit bezpečí.

pepak

Re:Easy password a html5, sifrovanie/security
« Odpověď #4 kdy: 27. 11. 2013, 21:24:28 »
Otázka/y: je to dobrý nápad? Nemám tam niekde logickú chybu?
Máš. Toto řešení je přesně stejně bezpečné, jako kdyby uživatel jako heslo zadával ty čtyři znaky nebo tři body.


pdx

Re:Easy password a html5, sifrovanie/security
« Odpověď #5 kdy: 27. 11. 2013, 21:43:42 »
>Proč převádět znaky na řetězce a hasnovat, když stačí zahashovat ty 4 znaky přímo
Každý znak užívateľovho hesla bude namapovaný na najaký string, všetky stringy sa na na koniec concatujú (čo jeden znak hesla to jeden string). Heslo bude dlhé. Z dlhého hesla sa bude šifrovať. Dlhé heslo, lepšia bezpečnosť. Hash zo 4 znakov < retazes zo styroch hashov

>To už má trochu lepší počet možných kombinací, ale zase by stačilo vzít indexy těch bodů. Všechno to hashování za tím může být dobré jen pro pálení cyklů procesoru, aby se zpomalilo bruteforce hledání.
Ak viem, že užívateľ zvolil kombináciu 1 + 2 + 3 u mňa to bude interne znamenať kombináciu sha1('lorem') + sha1('ipsum') + sha1('delor') = heslo na odsifrovanie

Šifrovanie na úrovni OS je fajn, len neposkytuje možnosť ako uložiť dáta v HTML5 app, tak aby neboli čitateľné pre iné apps a pre iných užívateľov. Šifrovanie disku je OK, len neposkytuje ochranu pred prístupom iných apps.

JardaP .

  • *****
  • 11 064
    • Zobrazit profil
    • E-mail
Re:Easy password a html5, sifrovanie/security
« Odpověď #6 kdy: 27. 11. 2013, 21:53:01 »
>Proč převádět znaky na řetězce a hasnovat, když stačí zahashovat ty 4 znaky přímo
Každý znak užívateľovho hesla bude namapovaný na najaký string, všetky stringy sa na na koniec concatujú (čo jeden znak hesla to jeden string). Heslo bude dlhé. Z dlhého hesla sa bude šifrovať. Dlhé heslo, lepšia bezpečnosť. Hash zo 4 znakov < retazes zo styroch hashov

Jak zabranite, aby ty znaky nekdo nejak neukradl (malware a pokud ty retezce budou u vsech uzivatelu stejne, bude to jeste lepsi o to, ze ani nebude treba malware k ukradeni)? Pak se misto crackovani hesla o ctyrech znaku bude resit vyber spranvych ctyrech retezcu a jejich poradi.

pdx

Re:Easy password a html5, sifrovanie/security
« Odpověď #7 kdy: 27. 11. 2013, 21:55:40 »
Máš. Toto řešení je přesně stejně bezpečné, jako kdyby uživatel jako heslo zadával ty čtyři znaky nebo tři body.

Odšifruj dáta ktoré boli šifrované klúčom s 500+ znakmi vs s 3 znakmi

pdx

Re:Easy password a html5, sifrovanie/security
« Odpověď #8 kdy: 27. 11. 2013, 22:10:15 »
Jak zabranite, aby ty znaky nekdo nejak neukradl (malware a pokud ty retezce budou u vsech uzivatelu stejne, bude to jeste lepsi o to, ze ani nebude treba malware k ukradeni)? Pak se misto crackovani hesla o ctyrech znaku bude resit vyber spranvych ctyrech retezcu a jejich poradi.

Malware-u nedokážem zabrániť (som sandboxovaný JS). Vie mi nietko povedať, či real-time rozbiteľné brutal force?

Re:Easy password a html5, sifrovanie/security
« Odpověď #9 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í).

Jenda

Re:Easy password a html5, sifrovanie/security
« Odpověď #10 kdy: 27. 11. 2013, 23:39:53 »
Máš. Toto řešení je přesně stejně bezpečné, jako kdyby uživatel jako heslo zadával ty čtyři znaky nebo tři body.

Odšifruj dáta ktoré boli šifrované klúčom s 500+ znakmi vs s 3 znakmi
Pokud vím, jakým způsobem se z těch 3 znaků vyrobilo těch 500 (a to nejspíš vím, protože se prostě podívám na zdroják té stránky), můžu si vygenerovat těch 64^3 500znakových sekvencí a vyzkoušet je během několika sekund na svém nepříliš výkonném počítači.

pepak

Re:Easy password a html5, sifrovanie/security
« Odpověď #11 kdy: 28. 11. 2013, 03:54:19 »
Máš. Toto řešení je přesně stejně bezpečné, jako kdyby uživatel jako heslo zadával ty čtyři znaky nebo tři body.
Odšifruj dáta ktoré boli šifrované klúčom s 500+ znakmi vs s 3 znakmi
No tak zrovna v tom tvém schámatu úplně triviálně. Pro mě za mě si ho klidně implementuj, ale pak se nediv.

JSH

Re:Easy password a html5, sifrovanie/security
« Odpověď #12 kdy: 28. 11. 2013, 10:10:34 »
Dlhé heslo, lepšia bezpečnosť.

Jenže to není dlouhé, ale jen zamaskované krátké heslo. Opravím tě, že "Hash zo 4 znakov >= retazes zo styroch hashov".

Uvědom si, jak a k čemu jsou hashe navržené. Napřed se všechno spojují dokupy a pak se to prožene jedním hashem. Opačně to nemá moc smysl. Jen to dává útočníkovi informaci, kterou část hashovaného textu má ještě blbě.

Citace
Šifrovanie na úrovni OS je fajn, len neposkytuje možnosť ako uložiť dáta v HTML5 app, tak aby neboli čitateľné pre iné apps a pre iných užívateľov. Šifrovanie disku je OK, len neposkytuje ochranu pred prístupom iných apps.
Před jinýma aplikacema se chrání pomocí přístupových práv na disku. Pokud může jiná aplikace sosnout ty zašifrované data a poslat je útočníkovi, pak je to dost v pytli. Na svém stroji se všechno louská tak nějak veseleji.
Pokud tohle v html5 aplikaci nejde, pak si aplikace která pracuje s důležitými daty nesmí nic ukládat na disk.

Pro zamyšlení :

Jak těžké by bylo pro zlou aplikaci vykreslit stejné přihlašovací okno, jako má ta tvoje?

pdx

Re:Easy password a HTML5
« Odpověď #13 kdy: 29. 11. 2013, 08:42:42 »
Vdaka vsetkym za odpovede ;)

Ano, je to hlupost. Ked mi to napadlo som si neuvedomil, ze napr. to "riesenie" 1, je az tragicky zle. Musim sa nad tym lepsie zamysliet a este raz vdaka.

pepak

Re:Easy password a HTML5
« Odpověď #14 kdy: 29. 11. 2013, 10:02:13 »
Musim sa nad tym lepsie zamysliet a este raz vdaka.
Obecně bych každému programátorovi doporučoval, aby pro věci jako autentizace uživatele, generování šifrovacích klíčů, obecně veškeré šifrování dat atp. používal už existující ověřené knihovny, a z nich speciálně co nejvíc vysokoúrovňové funkce (tzn. když budu chtít zašifrovat soubor, tak budu hledat nějakou funkci "ZašifrujSoubor" nebo "ZašifrujStream", nebudu se pokoušet poskládat to sám z "ZašifrujBlok"). Pak to jde udělat docela rozumně bezpečně. Pouštět se do nízkoúrovňových operací je recept na katastrofu i v případě, že máš nutný teoretický background.

Samozřejmě chápu, že to člověka láká, vymyslet úplně nové přihlašovací schéma, které bude současně pohodlnější i bezpečnější než současná schemata, ale zrovna v této oblasti je pravděpodobnost úspěchu poměrně nízká a pravděpodobnost katastrofálního selhání velmi vysoká.