Ano, i kdyz se vam to nezda, tak v pripade hashovani hesel znamena pomalejsi=lepsi (az do urcite urovne).
Sice s vami v podstate souhlasim, ale myslim, ze prehlizite ten ekonomicky rozmer - vzdycky jde o to, aby pro hackera bylo rozlousknuti natolik "drahe", aby se mu to nevyplatilo.
A vsechny diskutovane metody (SHA* misto MD5, saltovani) jsou jen metody, jak to hackerovi "zdrazit" az do meze, na ktere nema.
Aha, takže SHA* je bezpečnější, protože je větší, pomalejší a méně rozšířená. No když si to myslíte...
Napadlo vás třeba, že když je hesel dejme tomu 2^60, tak cracker může vcelku s klidem i SHA512 oříznout na dejme tomu 160 bitů a ten prostor ušetřit? Stejně si myslím, že tato diskuze je v době botnetů a terabytových disků tak nějak o hovnu. Pokud je heslo slabé, a cracker k němu dostane hash (a přepokládám taky sůl, je-li), tak to heslo dříve či později zjistí, nezávisle na hashovací funkci i (ne)solení.
Kazdopadne je tu par dulezitych kvantitativnich rozdilu - tim jak dlouho bylo MD5 popularni, tak uz ma kazdej druhej hacker svoji duhovou tabulku (nebo aspon vi, kde ji sehnat), existuji distribuovane sluzby na louskani MD5, atd.
SHA1 je min rozsirene, takze techhle tabulek a sluzeb uz je min (ale presto existuji). Hashu z rodiny SHA2 je jeste min a tim min je i nastroju na jejich rozlousknuti.
Jine kvantitativni rozdily jsou ve velikosti tech hashu (128 -> 160 -> 224 az 512 bitu) a tim padem nutneho hardware na ulozeni predgenerovanych tabulek a rychlosti spocitani (SHA1 je cca 6x pomalejsi).
Nejsou to rozdily principialni (kvalitativni), ale pouze kvantitativni - kazdopadne v kombinaci tak velke, ze SHA* je radove bezpecnejsi nez MD5.
Coz samozrejme nepopira to, ze saltovat je dobry napad, https taky, vyzadovat silna hesla, omezovat pocet pokusu o prihlaseni, zabezpecit databazi, atd. atd. atd.
Jenže vám pravděpodobně nedochází, že ta "plejáda postupů" funguje na MD5 stejně jako na SHA-cokoli, stejně jako na jakoukoli hashovaci funkci. Ten útok na kolize zase nejde použít proto, že z podstaty toho útoku musí být veden tím, kdo generuje ta hashovaná data (což je v tomto případě uživatel, který heslo tak jak tak zná).
Takže podepisovat (resp. věřit podpisu) MD5 cizího dokumentu je o hubu (to samé platí pro různé MD5 checksumy stažených souborů atd.), ale na MD5 hashovaném hesle nic není.
Je to dobry protiargument, ale neni hlavni. Hlavni protiargument je to v cem se neshodujeme, ale abych se neopakoval, odkazu na druhy odstavec toho clanku na security-portal.cz, tam je to popsane taky.
Kazdopadne tahle diskuse uz nikam nevede, myslim ze se shodneme v tom co je spravne a co spatne. Jenom se lisime v tom, co je vlastne ten bezpecnostni problem, ale zivot na tom nezavisi ;-)
Ano, ten alternativni cleartext nemusi byt slozen jen z "hezkych" znaku, to je dobry protiargument. Sice nevime, zda se Libimseti nejak brani proti zpracovani binarnich hesel, ale mozne to je - v takovem pripade by to prihlaseni nefungovalo.
Jeste je tu jeden efekt, pokud ostatni pouzivaji korektne salt, tak heslo, ktere ziskate jako kolizni k nesaltovane md5 nebude na ostatnich mistech fungovat.
Ale ja bych se spise obaval toho, ze dojde k nalezeni skutecneho hesla a ne toho kolizniho. Prece jen mnozina hesel delky 8 znaku je konecna a relativne nevelka. Pokud by heslo bylo nesaltovane, tak pro tyto delky hesel jsou uz md5 spocitane.
Samozrejme budete mit problem najit heslo sve oblibene uzivatelky, ale pokud problem postavite tak, ze chcete hesla libovolnych 10.000 uzivatelu, tak tu databazi hesel prolamete at tam bude hash jakykoliv. Verim tomu, ze pocet uzivatelu s heslem aaaa1111 nebude nijak maly. Na druhou stranu, takove heslo asi nebudou mit nikde jinde, protoze jine sluzby s tak prisnymi pozadavky na hesla neprudi ;-)
Ja bych na to take nespolehal, jenom jsem reagoval na "...kolizni heslo (tedy takove, ktere ma stejnou MD5ku a jde se s nim tedy prihlasit)".
Aby bylo jasno, ja si take myslim ze meli pouzit SHA[12] nebo alespon salt k MD5. V te diskusi jsem se jenom chtel trochu uklidnit ty, kteri hlasali ze "pouziti MD5 neni oproti cleartextu zvyseni bezpecnosti". Zvyseni to je, a vyrazne. Ale melo byt zvoleno lepsi reseni, v tom se shodujeme.
Druhý odstavec: Tak na to bych nespoléhal (ani na to, že bude těžko předpokládané délky, ani na to, že neproleze vstupním formulářem a ani na to, že útočník tento formulář použije)
Ehm, lze najit dva nestejne vstupni cleartexty, ktere povedou ke stejne MD5. Porad jeste neni (v rozumnem case) mozne k nejakemu konkretnimu MD5 hashi najit odpovidajici "alternativni" cleartext".
Tvrzeni "lze se s nim prihlasit" je trochu silne, protoze onen "nahradni" cleartext bude zrejme nejaky binarni sum tezko predpokladane delky, takze je mala sance ze by prolezl vstupnim formularem pro heslo. Ale to uz jsem trochu moc hnidopich, neberte to prosim ve zlem.
Doplneni:
- v roce 2004 nasli ty kolize cinani a pak v roce 2007 nasel tym kolem Vlastimila Klimy zpusob, jak je spocitat jeste 3-6 rychleji (dle: http://eprint.iacr.org/2005/075 )
- SHA256 je zrejme jeste lepsi volbou
To jej vazne nekdo v lednu 2009 konecne implementuje a hlasa, ze tim byla zvysena bezpecnost?
Od roku 2004 je znamy rychly postup, jak najit kolizni heslo (tedy takove, ktere ma stejnou MD5ku a jde se s nim tedy prihlasit), takze si tim oproti plaintextu takrka nepomohli.
Pritom reseni je pomerne jednoduche - pouziti SHA1 nebo nektereho jineho v soucasnosti doporucovaneho algoritmu.