Názory k článku
Obchodu Mall.cz unikla hesla, jsou jen slabě zahešovaná
-
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? -
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.
-
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). -
Filip JirsákStříbrný podporovatelHlavně 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á.
-
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. -
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í.
-
Filip JirsákStříbrný podporovatel
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.
-
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íčů).
-
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.
-
KateStříbrný podporovatelSamotný 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.
-
Filip JirsákStříbrný podporovatel
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. -
KateStříbrný podporovatel
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?
-
Filip JirsákStříbrný podporovatel
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í.
-
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á)
-
Filip JirsákStříbrný podporovatel
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í). -
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číš . . .
-
Filip JirsákStříbrný podporovatel
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.
-
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.upcbroadband.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ě.
-
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
Jenda 17:26: Jistě, jenže o tom si můžeme leda tak psát my dva v diskusích.
-
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? -
Filip JirsákStříbrný podporovatel
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.
-
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čí.
-
Filip JirsákStříbrný podporovatel
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é. -
Jenda (neregistrovaný)
Pokud nepoužívají hash iterovaně (aspoň pár tisíc), tak lze vyzkoušet všechna cca 8 znaková hesla rychle i pokud by použili sha-256 nebo sha-3.
Pokud používají hash iterovaně, tak s trochu větším počtem iterací je bezpečná i MD5. Protože ze známé hashe se ani u MD5 nedá zjistit heslo, ktere by na danou hodnotu hashe pasovalo. MD5 je prolomená v tom smyslu, že útočník dovede vytovořit dvě různá hesla, která budou mít stejnou (dopředu neznámou) hash; zjistit heslo ke stávající hashi je mnohem těžší.
Použití bcryptu, scryptu a podobných algoritmů, které jsou na ověřování hesel určené, je samozřejmě lepší. -
Filip JirsákStříbrný podporovatel
Problém iterování i bcryptu, scryptu a podobných algoritmů, je v tom, že to jsou programátorská řešení, ne kryptografická. To, že je to bezpečnější, je zbožné přání autorů, z hlediska kryptografie to nikdy nikdo nezkoumal.
-
Jenda (neregistrovaný)
Poznámka: použití "lepší" funkce má podobný efekt, jako prodloužit heslo o dva náhodné znaky. Takže neurazí, ale zároveň to není nějaké magické řešení všech problémů.
(pokud heslo prodloužíš o dva náhodné znaky, zkomplikoval jsi ho 64^2 = 4096x. A PBKDF či scrypt typicky bývají 1000-10000x pomalejší)
-
wanabe-hacker (neregistrovaný)
Načo by niekto použival GPU na MD5, ja osobne som rozluskol všetky šifry z leaku badoo, konkretne seznam.cz emaily, bolo ich tušim cez 2 miliony, cez hashkiller uspešnost bola 90 percent, ak je dobrý tak dokáže rozlusknut tých 700 000 hesiel tak do 3 dní cez haskiller, potom stačí cez konkretne zranitelnosti na seznam.cz pomocou backonect proxy nasadit robota /burpsuite/ alebo stačí cez pop3 scanner, /najdete na githube/ overovat pristupy na dané učty.
Ale konkretne tato databaza može byt využitá na cielený marketing, ak unikli aj udaje o vyške objednávky, telefonne čisla, emaily možete sparovat s kokrétnymi užívatelmi s facebokom, možete to použiť ako vstupné dáta pre google adword, facebook kampane atd. atd.
Napríklad z badoo databázy dokázal facebook pomocou emailov identifikovat 50% užívatelov. Stačí využit jednu zranitelnost a možete spárovat email s konkrétnym užívatelom, alebo telefonne číslo, aj to sa dá.
Takáto databáza je už velmi cenná, pretože ak chcete vytvárat custom audience na facebook reklamy musíte použit bud email alebo telefonne číslo na identifikovanie. -
Filip JirsákStříbrný podporovatel
Nic mi nepřišlo, takže předpokládám, že už je moje heslo hashované dobře, ale důkaz chybí.
O hashování vůbec nejde, prakticky nezáleží na tom, jakou funkcí bylo heslo hashované. Unikla pravděpodobně nějaká starší záloha, takže jde o to, zda váš účet je novější než ta záloha. Mall.cz údajně připravuje nějakou aplikaci, kde to budete moci zjistit – a doufejme, že dají data k dispozici i https://haveibeenpwned.com/ Každopádně změnou hesla nic nezkazíte.
