Autor Zpráva
v6ak
Profil
Jsou v php4 jiné hashovací funkce než md5 a sha1? Pokud vím, tak obě byly prolomeny.
Acci
Profil
Používat obě funkce pro zahashování hesel je stále bezpečné.
Joker
Profil
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 ;)
Peca
Profil
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 :-)
v6ak
Profil
bezpečnost postavíte na tom, že se nikdo nedostane k hashům v databázi
To je můžu ukládat v plaintextu.

Dík, radši bych pro jistotu použil bezpečnější funkci, pokud bude.
v6ak
Profil
Peca: Nemusím použít GUI prohlížeče. Existují v různých jazycích různé funkce pro http. BTW: můžu použít alt+číslo.
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 ;)
Jak dlouho se to bude počítat?
Anonymní
Profil *
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...
error414-
Profil *
MD5 nebylo prolomeno tak jas si tu vetsina lidi mysli. Porad se musi sirit desinformace.
mila
Profil
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 .
error414-
Profil *
mila
je to tak
v6ak
Profil
Jasně, nejdůležitější je jednosměrnost, ale kolize nesvědčí o bezpečnosti. A hesla nalepená na monitoru v php neošetřím stejně tak jako zápornou inteligenci. O možnosti sniffování taky vím.
krteczek
Profil
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/ )
error414-
Profil *
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.
krteczek
Profil
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
error414-
Profil *
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
Profil
Jasně, s tím počítám. Konkrétně k heslům: chtěl bych k hashi ukládat i označení algoritmu a při přihlášení kontrolovat aktuálnost.
petrVan
Profil *
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!
v6ak
Profil
petrVan:
Jasně, s tím počítám. Konkrétně k heslům: chtěl bych k hashi ukládat i označení algoritmu a při přihlášení kontrolovat aktuálnost.
šufánek
Profil
..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.
v6ak
Profil
šufánek
Já bych to s tou solí řešil jinak, protože není problém vyčmuchat i timestamp a doplnit to do formuláře. Třeba DOM Inspektorem (Jak jsem říkal, není potřeba na stránku jít jak uživatel, do každého pole můžu dát co chci...).
BTW: Zde je problém s tím, že do DB nemůžu uložit hash.
llook
Profil
šufánek
Ten timestamp bych teda uchovával spíše na straně serveru v session. Aby se dala kontrolovat jednorázovost toho hesla.
v6ak
Profil
llook: Hlavně nesmí jít jedna sůl použít vícekrát.
Toto téma je uzamčeno. Odpověď nelze zaslat.