Diskuze: Šifrování whirlpool
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 50 zpráv z 58.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
http://www.php.net/…ion.hash.php
(ctrl + F - "whirlpool")
$myHash = hash( 'whirlpool', $salt . $password );
Ale netestoval jsem to...
Zde máš příklady hashů:
http://www.php.net/…ion.hash.php#…
Bohatě stačí 'sha512', md 2 až 5 už je prolomené.
Ještě ti doporučuji aby jsi hash osolil: http://www.php.net/…on.crypt.php#…
Prolomené to přímo není, ale existuje spousta databází různých řetězců a příslušných hashů, kde se dá dobře hledat a lámat zabezpečení hrubou silou.
se solí jsou ale podle mě neprolomitelné ne? kdy mám třeba nick a
heslo.
heslo "osolím" (mě to vždy rozesměje ) nickem a to už je docela dost
bezpečný ne?
A pak si změní nick a máš problém Sůl musí být vždy
zvlášť.
změní si nick? tak mu vygeneruju novej hash, to snad neni takovej problém
ne?
Trochu jsme se odchýlili od původní otázky, je to hashovací algoritmus, což znamená, že už ze své podstaty nejde zpětně rozšifrovat, hashe se používají pro kontrolní součty, ukládání hesel apod... proto je pro předání zprávy nepoužitelný
Pokud si k tomu vytvoříš ještě vlastní solící algoritmus tak by to
asi nemělo být možné v nějakém rozumném čase zlomit (míň jak tři
miliardy let )
Je to problém, když hash děláš z nicku a hesla. Ve chvíli změny nicku to ehslo už nemáš.
Bez znalosti hesla stejně ten nick nezměníš, takže je to jedno.
Já v tom nevidím problém... Mám uživatele, jeho heslo je uložený jako
hash, kde je heslo, a jako sůl mám nick... Mám tedy nějaký hash...
Uživatel si změní nick... Na "potvrzení", že je účet jeho zadá i
heslo... Pochopitelně zjistím jestli je heslo platné, a pokud ano, přepíšu
mu nick. A jelikož vím jak nick, tak heslo, můžu mu vytvořit i nový
hash.
Ale tak dál to tu řešit nebudem, diskuze neni o tomhle neni
Není to jedno. Jako přihlášený si můžeš změnit nick aniž bys měnil nebo bezprostředně předtím zadával heslo.
A co je špatného na tom, že při změně nicku musíš zadat heslo? Hesla budou ve větším bezpečí díky originální soli u každého a uživatel bude mít pocit (a podle mě právoplatný), že mu to jen tak nikdo nezmění...
Taková sůl mi nepřijde zrovna nejbezpečnější měl by to být složitější
systém. Takhle když ti na to přijdou...
K takové soli se přidává ještě permanentní sůl, která se v aplikaci nevyskytuje.
tak pokud to chceš mí über-super-mega-ultimate-bezpečný, tak jako sůl
dáš hash spojení: "nick+mail+datum_registrace+text(třeba název
stránky)+id_uživatele"... To už ti přijde dostatečně bezpečné?
Např. v PHP fusionu má každý vygenerovaný originální sůl a na admin heslo také zvlášť nepletu-li se?
Hash není šifra, přečti si tohle: http://www.itnetwork.cz/…ladani-hesel
A v čem je problém? Při autentizaci zašifruješ zadané heslo a výsledný řetězec porovnáš se stejně zašifrovaným heslem v DB.
Zrovna na té stránce máš autentizační proces chybně. Heslo se z databáze vůbec nevytahuje, porovnává se přímo v ní.
Ano. Mě vlastně šlo o to, co ukrývá už druhý příspěvek
/EDIT Já to blbě napsal, já vím, že se porovnává a nevytahuje.
Co je chybně? Pokud jsou v databázi uloženy sůl i hash, musíš záznam nejprve načíst, abys byl vůbec schopen ze zadaného hesla hash spočítat. Jakmile je záznam už jednou načtený, je zbytečné se znovu dotazovat databáze a testovat shodu.
Pokud je uživatelské jméno neplatné, předejte se zbytečným výpočtům.
Souhlasím s sdracem, že používat jako sůl ID nebo jméno uživatele způsobuje problémy. Nevidím v tom žádnou výhodu, jen nevýhody.
Nemusíš načítat vůbec nic. Stačí jediný SELECT, jehož výsledkem je id a další atributy hráče. Heslo ani sůl z databáze tahat nepotřebuji. Pokud heslo nesedí, nedostanu žádný výsledek, ušetřím tedy komunikaci.
Můžeš prosím uvést příklad, jak by takový SELECT vypadal? Asi nerozumím.
Posílám to i s kouskem PHP:
<?php
$auth = $pdo->prepare("SELECT id FROM user WHERE name=? AND password=SHA1(CONCAT(?, salt))");
$auth->execute($_POST["user"], $_POST["pass"]);
if ($dotaz->rowCount() == 0)
throw new Exception("Chybné jméno nebo heslo");
$user = $auth->fetch(PDO::FETCH_ASSOC);
Díky za příklad. Myslím, že algoritmus je stejný jako v článku, pouze jsi přesunul logiku do databáze. To samozřejmě udělat lze a někdy to může být i výhodné.
Článek byl míněn obecně a nepředpokládá použití databáze MySQL.
Nedávno jsem byl na přednášce o php a tam týpek ukazoval program který
za dvě sekundy rozšifroval md5 heslo z malých a velkých písmen o min
velikosti 5 takže nevidím
tady nikde to, že by to nešlo rozšifrovat + povídal o tom, že takové heslo
ještě se solí se dá taky docela rychle, že ted už je jak md5 tak sha512
rozšifrovatelne během chvíle. Nyní by se mělo používat bcrypt nebo tak
něco
JPP. Kdyby to bylo tak jednoduché, byl by kolem toho mnohem větší poprask, než "tam týpek ukazoval".
Pokud si někdo zvolí slabé heslo, tak mu nepomůže ani bcrypt.
Tu nejde o slabé heslo, tu jde o to že ta rychlost rozšifrování je vysoká když zadá min. 5 čísel a z malých a velkých písmen. mělo to něco přes 20M slov za sekundu. Jako ano, pokud má člověk slabě heslo tak jo, je to hned. Ale právě ukazoval na tom příkladu to, že md5 ani sha512 už se nedoporučuje z toho duvodu, že byly prolomeny a že pokud fakt bude někdo chtít bezpečný system bez děr, měl by používat něco, co ještě nebylo.
Je hrozně zavádějící označovat md5 jako šifru. Nahlížej na to
raději podobně jako na kontrolní součet. Když si budu myslet
tři čísla od 0 do 9 a oznámím ti jejich součet, poměrně málo
pokusů ti stačí na to, abys odhalil, jaká čísla jsem si myslel.
Když ti ale oznámím součet padesáti čísel, budeš mít mnohem
větší problém. Ale pořád to půjde, když tě nechám dělat tolik
pokusů, kolik budeš chtít. Když ti ale dám jen tři pokusy,
prakticky nebudeš mít šanci. A právě v tomto smyslu se md5
používají. K rychlému ověření shody. Pokud ti nějaký člověk
ukázal, že heslo o pěti znacích rychle prolomí, je to proto,
že měl libovolně mnoho pokusů. Nic víc.
najlepsie je pouzivat hashovacie algoritmy, ktore su narocne na
vypocty(bcrypt). Mozno spomalia prihlasovanie uzivatela, ale v pripade uniknutia
DB (hashov) takmer znemoznia desifrovanie. Samozrejme pouzivanie SALTu tiez sa v
tomto pripade silno odporuca
Dá se také hashovat iterativně, spustíš třeba md5ku se solí v cyklu a výsledek dáš do SHA512 s další solí, řeší to ten samý problém.
Bohužel, neřeší, složitost problému SHA512(heslo) je úplně stejná jako složitost SHA512(for i in 0..100 x = MD5(x)).
Asymptoticky je to sice stejné, ale prakticky to trvá mnohem, mnohem déle, když zvolíš konstantu v řádu stovek a útočníkovi velmi znepříjemníš život. Sehnat 300x výkonnější procesor přeci jen není tak snadné. Časovou složitost bcrypt neznám.
Zásadní rozdíl je v tom, že amatérismus do security
nepatří
Dále existuje několik předpokladů:
Libovolné řešení, které navrhnete, viz SHA512(for 0..1000 MD5(salt(pswd))) je stejně bezpečné jako základní řešení SHA512(salt(pswd)) z toho důvodu, že už SHA512 bylo navrženo jako bezpečné. Laický názor je, že když smícháme dvě bezpečná řešení, dostaneme bezpečné řešení na druhou, ale opak je pravdou.
Sorry, že to tak musím říct, ale v tomhle vláknu je spousta blábolů. Viz TomBenovo vysvětlení "kontrolní součtu" - mně by na jeho příklad stačil jeden tip a budu vědět řešení (a dokonce i optimální), protože jsem matematik. Nebo Snorlax, který si plete pojmy o dojmy a plácá pátou přes devátou.
Ze základů hashovacích funkcí:
Například MD5 a SHA1 byly zkompromitovány, nebyly rozbity. Rozdíl je v tom, že existuje důkaz pro porušení pravidel (b) a (e), ale není známý postup pro nalezení řešení jednosměrné funkce v čase lepším než O(2^x). V případě MD5 se povedlo drasticky snížit K a zmenšit doménu hledaných hodnot.
Jakákoliv vaše snaha o "vylepšení" takové funkce F vede zpravidla k porušení některého z pravidel. Všechny kryptografické algoritmy se navrhují s těmito ohledy a pečlivě se testují celé měsíce, než se dojde k uspokojivému výsledku.
Pokud použijete SHA(salt(heslo)), budete mít nejvyšší úroveň bezpečnosti, jakou sami dokážete dosáhnout.
Zájemci by si měli poslechnout přednášku od profesionálů, jak hackovali XBOX: http://www.youtube.com/watch?…
Napadl mě příklad, na kterém si můžeme hezky vysvětlit, proč se nemají dělat vlastní řešení.
Budu mít vlastní funkci F, která vezme vstup a zakóduje ho ve dvou fázích:
Jedná se o velice jednoduchou funkci pro ukázkový příklad, ale SHA a AES algoritmy fungují na velice podobném principu.
F(12345678):
1) 12345678 -> 21436587
2) 21436587 -> 14365872
F(12345678) = 14365872
F(14365872) = 16385274
F(16385274) = 18325476
F(18325476) = 12345678 ... ups
Takže platí, že F(F(F(F(x)))) = x, ale nevadí.
Co se stane, když udělám H = F(for i in 0..1001 F(x))? Platí H = F(x)!
Tohle je důvod, proč vlastní "vylepšení" algoritmů nezvyšují bezpečnost. Zvyšují pouze vlastní pocit o bezpečnosti.
Máš samozřejmě pravdu. Netvrdil jsem, že se zvýší bezpečnost toho hashe, ale doba jeho prolomení. Docela by mě zajímala časová složitost lepších algoritmů, jejichž implementace jsou běžně k použití.
Myslím si tři čísla jejich součet je 13.
Jaká to jsou?
Máš jeden tip, použij ten svůj optimální.
9 4 0 a je to ten, ktery sis myslel, protoze pracujeme s hashem a nikde nemas sva cisla ulozena, takze nemuzes dokazat, ze to neni pravda.
Ani doba "prolomeni" se nezvysi, protoze funkce je jednosmerna a prolomit ji neumime. Jak jsem psal, dulezita je velikost range a domeny funkce a tenhle postup je nezvetsuje, pouze aplikuje urcitou transformaci. Takovy cyklus se uz deje uvnitr SHA a povazuje se za bezpecny, takze neni duvod ho jeste pridavat "ven". Pokud se najde postup pro rozbiti vnitrniho cyklu, pak vnejsi cyklus ztrati take na vyznamu.
Tady jde o situaci, když ti někdo ukradne celý backend a začne dělat dictionary attacky na jednotlivá hesla. Obrany jsou dvě, hlavní je mít u každého hesla jinou sůl. Tím pádem pro zjištění n hesel musí začínat n krát od nuly. A tou druhou je docílit toho, aby takový útok trval co možná nejdéle. Když bude hash trvat pod milisekundy, tak to má velmi rychle. Jakým způsobem bys toto tedy řešil?
dale uz to, co pises
vetsinou dojde ke kradezi zaloh spise nez backendu, jeste casteji to byvaji primo zamestnanci, takze programatori nesmi byt admini, admini nesmi mit pristup ke zdrojakum
Furt solit, ale čím když ne třeba nickem nebo IDčkem? Náhodným řetězcem který popřípadě ještě zahashujeme?
Popíšu ti způsob, jak lze zajistit trochu vyšší úroveň zabezpečení.
Optimálně použiješ dvě hodnoty:
hash = SHA512(SALT-1 + heslo + SALT-2)
Pro útok, který popisuje David Hartinger@, musí útočník:
Mimochodem, pokud by se útočníkovi podařilo projít všemi kroky, které popisuji výše, tak už je to ztracené a nemá smysl řešit hesla. V tuhle chvíli je volný přístup k libovolné (i šifrované) informaci v systému, jako jsou čísla kreditek, sociálního pojištění, bankovních účtů, atd.
Zobrazeno 50 zpráv z 58.