Hlavní navigace

Vlákno názorů ke zprávičce Obchodu Mall.cz unikla hesla, jsou jen slabě zahešovaná od Jan S - To mi stejne neleze do palice. Pokud to...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 28. 8. 2017 9:32

    Jan S (neregistrovaný)

    To mi stejne neleze do palice. Pokud to chapu spravne, hashovaci funkce z principu nejsou proste. Tzn. pro jednu funcni hodnotu (f(x)) mam bambilion promenych (x). Zaroven jsou funkce navrzeny tak, ze mala zmena x ma za nasledek radikalni zmenu f(x). Pokud tedy unikne databaze neosolenych hashu, tak pokud heslo neni z nejake sady hesel se znamymi hashy, samotna hesla z toho vytahnout nelze. Takze pokud je heslo i slabsi, ale obskurni, pro zneuziti na jine sluzbe by ta jina sluzba musela pouzivat neosolene hashe se stejnou funkci. A je uplne burt, jaka je hashovaci funkce. V jakem smyslu je tedy prechod na jinou hashovaci funkci zvysenim bezpecnosti, pokud to neni spojeno alespon s osolenim?
    Jinak, i unikly hash hesla staci k nabourani se do uctu. Co se v tomto ohledu zmeni, kdyz hash bude osoleny? Jen to, ze se hash neda pouzit jinde?

  • 28. 8. 2017 9:48

    mngnt (neregistrovaný)

    Pred nedavnom tu bola spravicka o tom, ze uz je mozne vytvarat kolizie v sha-1 hashoch. Tzn ak ma utocnik pristup k nesolenemu sha-1 hashu mojho hesla, bude moct najst ine heslo s tym istym hashom. Co je mu v tomto pripade rovnako dobre ako moje povodne heslo, do uctu na mall sa dostane.

  • 28. 8. 2017 10:45

    aaa (neregistrovaný)

    Kolizia je ina vec: vymyslim dva stringy x, y, ze hash(x)=hash(y). Elektronicky podpis pouziva hash, takze ti mozem podstrcit na podpisanie x a ty zaroven neumyselne podpises y.

    Neznamena to, ze by som prelomil vsetky hashe.
    Priklad: lubovolna hashovacia funkcia, co nakoniec spravu prenasobi hodnotou prveho bajtu. Ked mi podpises "ahoj" (hash 30697abc), tak s tym nespravim nic. Kolizia je, ze ti dam spravu "\0 je null byte" (hash 0), ty mi ju podpises a ja budem poznat inu spravu, ktora ma rovnaky hash "\0 cely majetok porucam aaa" (hash zase 0).

  • 28. 8. 2017 12:14

    tecik (neregistrovaný)

    Rainbow tables + ssd relativne za par kacek a uz to tak hrozne neni .. ale jasne, narocnost na lamani vseho by byla eromni .. moc bych se toho nebal (realnych dopadu)

  • 28. 8. 2017 17:20

    Jenda (neregistrovaný)

    > Rainbow tables + ssd relativne za par kacek a uz to tak hrozne neni

    Ne, pokud to heslo má alespoň 80 bitů entropie (což password managery normálně generují), tak ti nepomůže vůbec nic.

  • 29. 8. 2017 9:22

    Tunak (neregistrovaný)

    Sha-1 sice pry prolomit lze, ale zaroven u roho uvadeli, ze pronajem amazoniho cloudu, na kterym to bezelo, je stal cca 700 000Kc za 1 hash. Takze by to melo vyznam napr u elektronicky podepisovanych smluv, ale ne u uctu mall.cz

  • 29. 8. 2017 10:02

    Filip Jirsák

    Hlavně ale pro SHA-1 umí nalézt kolize 1. řádu (tj. vyrobit dva dokumenty se stejným hashem), pro lámání hesel by ale bylo potřeba umět nalézt kolize 2. řádu (tj. pro zadaný hash umět vytvořit dokument). Jinak řečeno, ten známý útok na SHA-1 se hashování hesel vůbec netýká.

  • 28. 8. 2017 9:51

    Honza (neregistrovaný)

    Já to chápu tak, že z neosolené MD5 haše hesla jde získat vzory a jde se dopátrat k tomu, že heslo je třeba janicka25 (nebo bambilion jiných) mnohem rychleji než zkoušením možných hesel. V případě bezpečné haše by to jinak nešlo.
    A pokud víte, že heslo je janicka25 (nebo bambilion jiných), tak to na 95% bude opravdu ta janicka25.

  • 28. 8. 2017 17:25

    Jenda (neregistrovaný)

    > Já to chápu tak, že z neosolené MD5 haše hesla jde získat vzory a jde se dopátrat k tomu, že heslo je třeba janicka25 (nebo bambilion jiných) mnohem rychleji než zkoušením možných hesel.

    Právě že nejde. Ani u té velmi prolomené MD5 se tohle neumí lépe než zkoušením různých vstupů.

    Pointa "silnějších" hashovacích funkcí je v tom, že jsou "pomalé" - takže to zkoušení různých vstupů také půjde pomalu.

    Ale tohle všechno se hodí při používání hesla pro symetrickou kryptografii - u on-line autentizace k tomu není naprosto žádný důvod. Není problém vytvořit protokol, při kterém se heslo na druhou stranu vůbec nedostane. Jenom z mně neznámých důvodů ho prohlížeče ani webservery neimplementují.

  • 28. 8. 2017 19:32

    Filip Jirsák

    Pointa "silnějších" hashovacích funkcí je v tom, že jsou "pomalé" - takže to zkoušení různých vstupů také půjde pomalu.
    Nikoli, pointa silnějších hashovacích funkcí je především v tom, že jsou kryptograficky odolnější, tj. nemají známá místa, která umožňují při výpočtu „podvádět“, případně slabiny, o kterých si kryptologové myslí, že by k něčemu takovému mohli vést. A dále jsou silnější takové hashovací funkce, které (při splnění předchozího bodu) mají delší výstup, tj. drží si dostatečný odstup od útoků hrubou silou.

    Pomalost hashovacích funkcí se řeší prakticky jen v souvislosti s hashováním hesel jako „ochranou“ před úniky – oba dva víme, že správné řešení je takové, kdy server heslo vůbec nezná, a zná buď veřejný klíč, nebo hash hesla uživatele, které je pro danou službu unikátní. Místo toho se řeší nesmyslné tanečky z hashováním hesel na serveru, jenže to je málo esoterické, tak se vymyslelo pomalé hashování nebo iterované hashování.

    Přitom – když už se vylepšuje to hashování – by při těchhle únicích databází nebo jejich záloh mnohem více pomohlo, kdyby aplikace měla ještě jednu globální sůl uloženou mimo databázi (prý se tomu říká „pepř“), ke které se ten, kdo získá jenom databázi, nedostane.

  • 28. 8. 2017 19:56

    Jenda (neregistrovaný)

    > Nikoli, pointa silnějších hashovacích funkcí je především v tom, že jsou kryptograficky odolnější

    "Silnějšími" funkcemi jsem zde nemyslel běžné moderní hashe jako SHA-2/3, ale funkce pro derivaci klíče (měl jsem to asi napsat lépe).

    > Pomalost hashovacích funkcí se řeší prakticky jen v souvislosti s hashováním hesel jako „ochranou“ před úniky

    Ještě se řeší při lokálním symetrickém šifrování (např. šifrování disku, password manageru nebo privátních klíčů).

  • 29. 8. 2017 8:22

    j (neregistrovaný)

    Html auth (digest) je presne to co chces ... ale prej se to z nejakyho duvodu nelibi soudruhum provozovatelum serveru ... Je fakt, ze na strane browseru prozmenu neni implementovany "odhlaseni", takze se odhlasit nejde. Uplne stejne se pak browsery umej prihlasovat klicem ... kde to ma uplne stejnej problem - neda se odhlasit.

    To vis, proto tu mame ten vopensoorc .... aby resil jaky bude logo, a jestli ten co ho dela je lesba nebo teplous.

  • 28. 8. 2017 9:55

    Kate

    Samotný hash k nabourání se do účtu nestačí. Je potřeba najít buď přímo řetězec ze tkerého vznikl, nebo kolizi - jiný řetězec který dá stejný hash. U složitějších algoritmů kde nepřipadá v úvahu bruteforce k lámání hesla pomáhá „rainbow table“ - něco jako slovník hesel, jen pro kombinaci string -> hash. Prevence proti tomu a proti tomu aby šla případná kolize použít i jinde je právě sůl.

    Problém md5 je, že to není složitý algoritmus. U md5 ten bambilión kombinací vyrobíš hrozně rychle, takže súl pro tebe není problém. A vzhledem k tomu že má útočník celou databázi a nejspíš tedy i případně použitou sůl, je vylámání originálních hesel jen otázka času.

  • 28. 8. 2017 10:02

    Filip Jirsák

    Takze pokud je heslo i slabsi, ale obskurni, pro zneuziti na jine sluzbe by ta jina sluzba musela pouzivat neosolene hashe se stejnou funkci.
    Ani to by útočníkovi nepomohlo, protože u webových služeb (o kterých je řeč) posílá klient heslo v otevřeném tvaru a hashování provádí až server.

    V jakem smyslu je tedy prechod na jinou hashovaci funkci zvysenim bezpecnosti, pokud to neni spojeno alespon s osolenim?
    O zvýšení bezpečnosti nejde. Jediný minimální efekt je v tom, pokud je nová hashovací funkce výpočetně náročnější, že to útočníkovi lehce zkomplikuje útok hrubou silou na vybrané hashe.

    Přechod na novou hashovací funkci se dělá především proto, že oslabené hashovací funkci se obecně nedůvěřuje, přestává se používat, přestává být podporována v knihovnách atd. – takže jejím dalším používáním si jen komplikujete situaci. Útok, který by bylo možné použít k prolomení hesel (tj. ke známému hashi dokážete vygenerovat odpovídající dokument), je pro MD5 popsán pouze teoreticky (a nejspíš by vám z toho vylezl dokument, který do políčka pro heslo nezadáte), pro SHA-1 takový útok vůbec není znám. Popsané útoky na MD5 i SHA-1 spočívají v tom, že dokážete vygenerovat dva různé dokumenty se stejným hashem – to pro hashování hesel nemá žádný význam.

    Co se v tomto ohledu zmeni, kdyz hash bude osoleny?
    Nemůžete použít předpočítané hashe, tj. zbývá jen útok hrubou silou.

  • 28. 8. 2017 10:14

    Kate

    No právě. Ta hrubá síla u MD5 není zas až taková překážka, když moderný GPU zvládají provést i stovky milionů MD5 hashů za vteřinu. http://bvernoux.free.fr/md5/index.php Tak proč řešit nějaké kolizní algoritmy?

  • 28. 8. 2017 10:58

    Filip Jirsák

    Problém všech těchhle algoritmických zpomalovačů útoků hrubou silou je v tom, že přidávají složitost v nízkých jednotkách řádů. Což zase útočník dokáže kompenzovat tím, že to nebude louskat na CPU běžného počítače, ale na GPU, nebo to bude dělat distribuovaně, nebo si holt nějakou dobu počká. Zkrátka pokud má uživatel slabé heslo, provozovatel webu to nezachrání.

  • 28. 8. 2017 11:10

    NULL (neregistrovaný)

    "Zkrátka pokud má uživatel slabé heslo, provozovatel webu to nezachrání"

    Neřekl bych, může vynucovat silné heslo . . .

  • 28. 8. 2017 17:26

    Jenda (neregistrovaný)

    > Problém všech těchhle algoritmických zpomalovačů útoků hrubou silou je v tom, že přidávají složitost v nízkých jednotkách řádů.

    Já teda vidím hlavní problém v tom, že řeší "problém", který vůbec neměl nastat - to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat. (u lokálního šifrování je samozřejmě situace jiná)

  • 28. 8. 2017 17:57

    NULL (neregistrovaný)

    "to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat"

    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .

    Jinak je to samozřejmě až několikátá zóna, tedy po všech možných zabezpečeních, a kdoví čem, eventualita ztížit co nevíce možnost využití uniklých dat.

  • 28. 8. 2017 18:52

    Jenda (neregistrovaný)

    > Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .

    Používal jsi někdy SSH s klíčem?

    První nástřel: Z hesla+domény+saltu vygeneruju deterministicky RSA klíč, veřejnou část a volitelně salt pošlu na server, a pak se autentizuju běžným challenge-response RSA.

  • 28. 8. 2017 19:12

    Filip Jirsák

    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .
    Třeba tak, že hash spočítá už prohlížeč na základě výzvy serveru. Server pak může mít uložen jenom hash hesla a heslo v otevřeném tvaru se nemusí vůbec dozvědět. Takhle funguje třeba HTTP Digest autentizace. Akorát k tomu chybí část pro vytvoření hesla a prohlížeče k tomu mají otřesné UX (např. chybí funkce odhlášení).

  • 29. 8. 2017 8:03

    NULL (neregistrovaný)

    @Filip Jirsák Včera 19:12

    Aha, takže Jirskák je schopen vyrobit systém, kde hesla nikdy neuniknou. Gratuluji, založ firmu, myslím že uděláš díru do světa a budou se o tebe tahat nejlepší firmy světa. Myslím že tvé génium dosáhlo nové úrovně.


    Po předchozích zkušenostech zrovna přikládám dotčený výrok:

    NULL (neregistrovaný) ---.freepoint.cz Včera 17:57

    "to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat"

    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .

  • 29. 8. 2017 10:12

    Filip Jirsák

    Aha, takže Jirskák je schopen vyrobit systém, kde hesla nikdy neuniknou.
    Kde jsem něco takového psal? Aha, nikde, to si zase jen NULL bohapustě vymýšlí.

    Po předchozích zkušenostech zrovna přikládám dotčený výrok:
    NULL (neregistrovaný) ---.freepoint.cz Včera 17:57
    "to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat"
    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .
    Tak zaprvé, dotčený výrok není můj, napsal ho Jenda. Za druhé, byly tu uvedeny minimálně dva způsoby, jak se to dá zařídit – využití asymetrické kryptografie, tedy dvojice veřejný a soukromý klíč. Například konkrétně v HTTPS tedy přihlášení klientským certifikátem. Druhý v diskusi uvedený způsob je metoda výzva–odpověď, který se používá třeba v některých implementacích přihlašování Windows (NTLM), nejstarší implementace pro HTTP se pak nazývá HTTP Digest.

    Vygooglit si to evidentně neumíte, tak jsem vám dal základní odkazy rovnou do textu. Nečekám, že byste pochopil princip, jak to funguje, ale snad už aspoň nebudete tvrdit, že to neexistuje.

  • 29. 8. 2017 11:22

    NULL (neregistrovaný)

    @Filip Jirsák

    Ano Jirsáku, napsal to Jenda, přesto jsi to papuškoval. Tak se na to podíváme:

    Jenda (neregistrovaný) ---.net.upcbroad­band.cz Včera 10:58

    > Problém všech těchhle algoritmických zpomalovačů útoků hrubou silou je v tom, že přidávají složitost v nízkých jednotkách řádů.

    Já teda vidím hlavní problém v tom, že řeší "problém", který vůbec neměl nastat - to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat. (u lokálního šifrování je samozřejmě situace jiná)

    >>>>>>>>>

    NULL (neregistrovaný) ---.freepoint.cz Včera 17:57

    "to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat"

    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .

    >>>>>>>>>

    Filip Jirsák 100 Bronzový podporovatel Včera 19:12

    Hmmm, to bych tě chtěl vidět, jak tohle zaručíš . . .
    Třeba tak, že hash spočítá už prohlížeč na základě výzvy serveru. Server pak může mít uložen jenom hash hesla a heslo v otevřeném tvaru se nemusí vůbec dozvědět. Takhle funguje třeba HTTP Digest autentizace. Akorát k tomu chybí část pro vytvoření hesla a prohlížeče k tomu mají otřesné UX (např. chybí funkce odhlášení).

    =============­========================­========================­==

    Co z toho?

    1)
    Aha, takže Jirskák je schopen vyrobit systém, kde hesla nikdy neuniknou.
    Kde jsem něco takového psal? Aha, nikde, to si zase jen NULL bohapustě vymýšlí.

    Jenda napsal že je chyba, že vůbecunikl hash. Já na to že tomu nikdy na 100% nezabráníš.A ty na to, že
    "
    Filip Jirsák 100 Bronzový podporovatel Včera 19:12
    Třeba tak, že hash spočítá už prohlížeč na základě výzvy serveru. Server pak může mít uložen jenom hash hesla a heslo v otevřeném tvaru se nemusí vůbec dozvědět. Takhle funguje třeba HTTP Digest autentizace. Akorát k tomu chybí část pro vytvoření hesla a prohlížeče k tomu mají otřesné UX (např. chybí funkce odhlášení).
    "

    Pominu to, že stejně se ten hash musí dostat na server a tedy je stejně možnost, že odtud opět unikne, jenom se přidalo další potenciálně slabé místo.
    Nepominu, že se to k Jendovému a mému příspěvku o uniknutí hashů nijak nevyslovuje, jenom do toho zatahuješ zase nějaké svoje nesouvisející moudra.

    2)
    Tak zaprvé, dotčený výrok není můj, napsal ho Jenda. Za druhé, byly tu uvedeny minimálně dva způsoby, jak se to dá zařídit – využití asymetrické kryptografie, tedy dvojice veřejný a soukromý klíč

    Ano, což se k uniknutí hashů ze serveru vyslovuje. Aha.

    Piš si co chceš, nevím proč do toho zatahuješ mě.

  • 29. 8. 2017 12:22

    Filip Jirsák

    Jenda napsal že je chyba, že vůbec unikl hash.
    Lež. Jenda napsal, že je chyba, že se na server vůbec dostalo nešifrované heslo. Sám jste zde příslušnou větu už mnohokrát citoval: „to heslo se totiž v první řadě na druhou stranu vůbec nemělo dostat“.

    Já na to že tomu nikdy na 100% nezabráníš.
    Aha, tím se to vysvětluje. Vy jste jenom nepochopil, co Jenda napsal. Respektive asi nějak nejste schopen rozlišit mezi pojmy „hash“ a „heslo (v otevřeném tvaru nebo jeho ekvivalent)“

    Pominu to, že stejně se ten hash musí dostat na server a tedy je stejně možnost, že odtud opět unikne, jenom se přidalo další potenciálně slabé místo.
    To klidně pominout můžete, protože to je nepodstatné. Podstatné je to, že server zná jen osolený hash hesla, takže únik toho hashe neohrozí nic jiného, než účet na tom jednom serveru.

    Nepominu, že se to k Jendovému a mému příspěvku o uniknutí hashů nijak nevyslovuje, jenom do toho zatahuješ zase nějaké svoje nesouvisející moudra.
    Jak už jsem napsal výše, problém je jenom v tom, že si pletete „hash“ a „heslo“, takže jste nepochopil ani Jendův příspěvek, ani následné reakce na něj.

    Ano, což se k uniknutí hashů ze serveru vyslovuje. Aha. Piš si co chceš, nevím proč do toho zatahuješ mě.
    Moje reakce se vztahují k tématu diskuse. Jediné reakce mimo jsou ty vaše, ale už se vysvětlilo, čím to je – pletete si „hash“ a „heslo“, takže jste nepochopil ani Jendův příspěvek, ani následné reakce na něj.

  • 28. 8. 2017 10:51

    Jan S (neregistrovaný)

    Diky za odpovedi, asi tomu zacinam rozumet...
    Vtip je v tom, ze pro heslo je i nejaky predpoklad , napr. ze to neni 5MB soubor, coz ten bambilion asi dost snizuje...
    Rainbow table: to je na tom md5sum tak spatne, ze kdyz je znamy hash pro "janicka25" a ja mam heslo "janicka27", tak se da uhadnout?
    "Samotný hash k nabourání se do účtu nestačí." Nejak jsem mel dojem, ze se nekdo holedbal ze pro nabourani do uctu mu staci hash... Nebo to je jen pro pripady, kdy je hash pocitany u klienta?

  • 28. 8. 2017 11:09

    NULL (neregistrovaný)

    IMO, holedbal, protože nejspíš zkusí udělat to, co ti píší výše. Ono se to taky čas od času mění, bybly doby kdy byly hesla v plaintextu obvyklé, dneska už se kdekdo ! pozastaví ! nad hesly čistě v md5 a zítra, kdo ví?

  • 28. 8. 2017 11:36

    Filip Jirsák

    Vtip je v tom, ze pro heslo je i nejaky predpoklad , napr. ze to neni 5MB soubor, coz ten bambilion asi dost snizuje...
    Ono je to spíš opačně. Je určitý prostor všech možných hesel (délka, přípustné znaky). Útok hrubou silou znamená, že je vyzkoušíte všechny. Pokud výpočet hashe trvá déle, útočníka to trochu zpomaluje, ale není to moc významné. Mnohem významnější je rozšířit ten prostor možných hesel – což znamená, že uživatelé nemají používat jako hesla existující slova (pak je ten prostor redukován na slovník), hesla mají být dostatečně dlouhá a mají se používat různé znaky.

    Rainbow table: to je na tom md5sum tak spatne, ze kdyz je znamy hash pro "janicka25" a ja mam heslo "janicka27", tak se da uhadnout?
    Ne, tak špatně na tom MD5 není. U rainbow tables je (z pohledu útočníka) jediný problém – jak velký máte prostor pro uložení všech možných kombinací hesel. Když budete počítat 1 bajt na heslo (stačí nám řádový odhad), 8znaková hesla z malých písmen anglické abecedy uložíte do 200 GB. To dneska není problém. Když ta hesla budou moci obsahovat i velká písmena a číslice, a pořád necháte tu délku 8 znaků, potřeboval byste na to 200 TB. To už se dostáváme na hranice možností. Když ta hesla prodloužíte na 10znaková, dostanete se do řádu exabajtů.

    Nejak jsem mel dojem, ze se nekdo holedbal ze pro nabourani do uctu mu staci hash... Nebo to je jen pro pripady, kdy je hash pocitany u klienta?
    Ano, to je případ, kdy je hash počítaný u klienta. Což je mnohem bezpečnější varianta, protože pak heslo neputuje v otevřeném tvaru po síti (byť třeba šifrovaným kanálem) a hlavně se cílový server nikdy nemusí heslo v otevřeném tvaru dozvědět.

    On celý tenhle koncept, kdy heslo opouští uživatelův prohlížeč, je jedna obří bezpečnostní díra. Hashování hesel je spíš drobné maskování té díry než cokoli jiného.

  • 28. 8. 2017 17:34

    Jenda (neregistrovaný)

    > Když budete počítat 1 bajt na heslo

    Rainbow tabulky jsou mnohem efektivnější. Například u A5/1 je maximum řádově 1 bit na 500 klíčů (text a přednáška jak se to dělá), u MD5 AFAIK není limit prakticky dosažitelný, jenom potom prohledání tabulek bude trvat dlouho.

    > Ano, to je případ, kdy je hash počítaný u klienta. Což je mnohem bezpečnější varianta, protože pak heslo neputuje v otevřeném tvaru po síti (byť třeba šifrovaným kanálem) a hlavně se cílový server nikdy nemusí heslo v otevřeném tvaru dozvědět.

    Ještě lepší varianta je challenge-response, kde dokonce ani uniklý hash nestačí.

  • 28. 8. 2017 19:15

    Filip Jirsák

    Například u A5/1 je maximum řádově 1 bit na 500 klíčů
    V takovýchhle případech jde vždy o odhad řádů, tři řády sem nebo tam na tom nic nezmění. Pokud je něco zabezpečené jenom díky třem řádům, je to nezabezpečené.