Hashovací funkce v php 4

Používat obě funkce pro zahashování hesel je stále bezpečné.

v6ak
Minimálně SHA-1 je pořád bezpečná, což zjistíte i z toho článku na Wiki. U MD5 bych si tak jistý už nebyl, jelikož tam je možné i na běžném počítači najít kolizi během minuty. Nicméně to záleží na použití, na "běžném webu" si klidně vystačíte s MD5 a bezpečnost postavíte na tom, že se nikdo nedostane k hashům v databázi a když už jo, nepřečte si je přímo.

Jinak ale hashovací funkce je jenom algoritmus, navíc obvykle veřejně známý, neměl by být takový problém si ho v PHP napsat ;)

Ono se to dá prolomit, ale zkus do webového textového pole vložit všechny ascii hodnoty nejenom písmena a číslice. To bude asi trochu problém, takže tyto kolize jsou stejně nepoužitelné. Pro paranoiky: aplikuj md5 na md5, to prolomit nejde :-)

pokial mate na mysli md5 hash hesla ktore zadavate pri prihlasovani tak vedzte ze pokial pouzivate nesifrovany prenos tak to heslo sa da kludne "vycmuchat" nakym paket snifferom.. jeho nasledny hash md5 a porovnavanie s md5 v databazi je len z toho dovodu aby vam niekto kto ma pristup do databaze neukradol "surove" hesla..
ovsem priznajme si, ze databaza ked si stanovime dobre prava je omnoho bezpecnejsia nez nechraneny prenos, kcomu teda md5? dalo by sa povedat ze spolu s chraneny prenosom by to md5 malo zmysel...

MD5 nebylo prolomeno tak jas si tu vetsina lidi mysli. Porad se musi sirit desinformace.

Nejsem v tomhle moc zběhlý, ale pokud vím, tak to "prolomení" md5 funguje tak, že někdo našel dva řetězce se stejným otiskem. Vůbec to neznamená, že někdo najde druhý řetězec k vámi zvolenému (heslo) se stejným otiskem, nebo snad dokonce spočítá z otisku vzor..
Jestli se pletu, prosím, opravte mě.

Jinak samozřejmě existují mnohem větší nebezpečí. Od slovníkového útoku, přes útok hrubou silou, snifer po hesla nalepená na monitoru .

mila
je to tak

Dovolím si zde podat vysvětlení tak jak jsem tu kolizi pochopil já:
ta kolize nemá význam u textu který se běžně používá pro hesla, v tom případě je jednodužší slovníkový útok (6 (dneka už častěji 8) znaků v ASCII nejčastěji v rozmezi 48-128 (čísla + malá a velká písmena anglické abecedy), tady je nemožné najít jiný řetězec odpovídající md5 hashem tomu původnimu.
Tato kolize začíná být významná u binárních souborů, kde hrozí podstrčení něčeho jiného než co očekáváme. Typicky: běžně se disriubuují soubory s programy tak, že se vystaví na webu a k tomu souboru se udělá md5 hash, toho souboru (jeho podpis) který si po stáhnutí ověříme a teprve po kladném ověření se považuje soubor za správný. Tady nastupuje nebezpečí které ta kolize může způsobit:
Někdo může ve velmi krátkém čase najít (nebo i vytvořit) k souboru "A" soubor "B" který bude mít stejný md5 hash, ale obsahem bude jiný (prostě místo vámi očekávaného videa si stáhnete zavirovaný soubor který navenek (podle MD5) bude vypadat stejně.

Celý problém vznikl pravděpodobně proto, že se věřilo, že velké množství slabých, ale rychlých funkcí (algoritmů), může být dostatečně bezpečné, ono jde o čas a výkon který je nutno tomu spočítaní toho hashe dát.
Existují i silné jednosměrné algoritmy, jejich použití je však pro počítání kontrolního součtu tak náročné, že jsou pro běžný provoz například na webu, nepoužitelné.

celý tento text je vpodstatě zjednodušeným výtahem toho co jsem si o tomto problému přečetl za poslední cca rok.
významný pokrok v této oblasti má nasvědomí český kryptoanalytik Vlastimil Klíma ( http://cryptography.hyperlink.cz/ )

krteczek
Mas tam chybu, zatim neni mozne k souboru A a vztvorit Soubor B se stejnou hasi, Ale je moyne vztvorit soubor A a soubor B ktere busou mit stejnou has. Takze ja musim vytvaret oba dva soubory.

error414-: ano v současné době (pokud vím) nejde vytvořit soubor k hashi na požádání, to ovšem neznamená že by to v budoucnu nešlo.

už z možností kombinací 32 (40 u sha1) znaků dlouheho řetězce je jasné že je to konečné číslo pro nekonečně mnoho předloh, z čehož vyplývá, že lze nalézt ke každé předloze jinou se stejným hashem.

ještě k poznámce error414- pokud budu mít k dispozici soubor "A" mužu k němu vytvořit soubor "b", muj nazor je že by to šlo i jen se znalostí toho hashe, no dneska je to ještě nereálné
krteczek

krteczek
v bodoucnu bude mozne prolomit i MD7, Ja bych se zese tak md5 nebal (pri pouziti hesel). Jen je potreba psat systemy kde se lehce nahradi za jinou hashovaci fukci.

v6ak
Minimálně SHA-1 je pořád bezpečná, což zjistíte i z toho článku na Wiki. U MD5 bych si tak jistý už nebyl, jelikož tam je možné i na běžném počítači najít kolizi během minuty. Nicméně to záleží na použití, na "běžném webu" si klidně vystačíte s MD5 a bezpečnost postavíte na tom, že se nikdo nedostane k hashům v databázi a když už jo, nepřečte si je přímo.

Kolizi sice mozne najit je a trva to opravdu do minuty, ale k md5hashi najit retezec takovy, aby mel md5hash toho retezce byl stejny, jako je to heslo, tak to nikoliv!

..ještě k tomu sniffování. Já to řešim kódováním odesílanýho hesla client-side (někde jsem stáhnul javascriptovou f-ci md5). Data na cestě už jsou kryptovaný funkcí md5(heslo+timestamp), plus pošlu nezašiforvanej timestamp. Pro každej okamžik tak platí jiný (unikátní!) heslo - i kdyby ho někdo sniffnul, je mu to na nic.

šufánek
Ten timestamp bych teda uchovával spíše na straně serveru v session. Aby se dala kontrolovat jednorázovost toho hesla.