Bezpečně uložená hesla v db - hashování

HackForum

Bezpečně uložená hesla v db - hashování#
Zdravím,

nebudu to protahovat nějakým dlouhým proslovem, ale nejsem expert na kryptografii, takže mě zajímá, proč nepoužívat na příklad tento typ hashování...

for ($i="0"; $i < "1000"; $i++)
$pass = md5($pass);

Zkoušel jsem heslo o délce 4 znaky nějakým způsobem rozluštit, ale bez úspěchu, to snad ani nejde, ne? (respektive jde, ale bylo by to asi dosti pomalé a musel by se využít vlastní cracker, který by generoval bruteforce/slovník a každé slovo projel touto 1000x md5() ... Na luštění pár hesel by to šlo, ale co nějaké velké databáze? Tam by bylo zpomalení značné, či nikoliv?(benchmark jsem nedělal, jen odhaduji)

Kdyby jsme měli třeba 100 000 uživatelů v db, tak jaká by byla šance, že by se nám podařilo za přijatelnou dobu rozluštit aspoň 10%? Třeba této problematice dosti nerozumím, tak mě, prosím, případně poučte, ať se zase něco nového dozvím ;)

Akorát jsem se dočetl, že čím víc hashujeme(ale jen rozdílné typy hashování), tak tím se zvyšuje šance na "kolizi" z čehož moc moudrý nejsem.

Prosím o vysvětlení, jak se tedy věci mají...
Děkuji ;)
(odpovědět)
Shaim24.8.2011 13:54
re: Bezpečně uložená hesla v db - hashování#
vsechno, co se kolizi a oslabovani algoritmu tyce, je v kontextu hesel predevsim teorie, nad kterou je fajn se zamyslet, ale neomezovat se.

jak jsi sam naznacil, uz tim, ze neprovedes jen klasicke sha1() nebo md5(), vyradis ze hry veskere dostupne rainbowtables. pokud s tim udelas jeste podobne harakiri, jako jsem uvedl napr. zde [link] tak si utocnik bude muset napsat i vlastni cracker, a to NIKOMU nestoji za to. ano, teoreticky je mozne prolomit hodne veci, ale je potreba to brat realisticky...
(odpovědět)
Emkei | E-mail | Website | PGP24.8.2011 15:19
re: Bezpečně uložená hesla v db - hashování#
Dobře, to jsem přesně chtěl vědět. Já jsem to pořád jen slyšel, jak dochází ke kolizím a podobně, ale pořád to byla jen teorie a teorie. Tak jsem dnes věnoval nějaký čas testování. Zkoušel jsem třeba string projet vším možným... Napsal jsem si na to cracker a výsledek? Ať jsem projel string čímkoliv, tak se tím prodloužila doba crackování... Žádné kolize a nic... Takže jinak řečeno, proč projíždět klasicky string jen 1x md5(), když to můžeme udělat třeba 5x a když útočník nemá informace o tom, jak to heslo je tvořeno, tak nemá šanci na to přijít...

Co se týče toho tvého řešení na které jsi posílal link, tak nějak podobně já hashuji již delší dobu, ale určitě je příjemná vychytávka ten sha-1 zkrátit na 32 charů a tudíž to vypadá jako md5 :) No... Abych to shrnul... (to je můj závěr...)

Pokud útočník nemá informace o tom, jak heslo vzniklo, tak nemá šanci rozlousknout vůbec nic... Nepočítáme, že heslo bude v plaintextu a nebo třeba jen 1x projeté skrze md5(), což bude první, co útočníka napadne, jelikož to tak dělá spousta lidí(valná většina bych řekl - taky jsem to tak před X lety dělal)...

Tzn, je jedno, jestli použijeme
for ($i="0"; $i < "1000"; $i++)
$pass = md5($pass);

nebo

function CreateHash($login, $password) {
$token = 'v6PiLd';
$hash = sha1(sha1($login.$password.$token));
$hash = substr($hash, 0, 32);

return $hash;
}

Liší se to akorát v tom, že tvá verze je elegantnější :)

Ovšem... Pokud útočník získá informace o tom, jak hashování probíhá, tak má varianta bude lepší, jelikož útočníka bude zdržovat, že každé heslo 1000x bude muset projet md5() a poté až pokračovat na další heslo. Nedělal jsem benchmark, ale myslím, že tam nějaké zdržení určitě bude...

No... Jdu udělat v rychlosti benchmark, ať máme něco v ruce ;)


Tak jo, benchmark hotový a myslím, že výsledky jsou zcela jednoznačné...
Napsal jsem si cracker, který proběhl každou fci 100 000x (delka hesla 5 znaku)

Výsledek:
"moje" metoda: 6,9434 s / 100 000 pokusů
tvoje metoda: 0,2838 s / 100 000 pokusů
1x md5(): 0,0986 s / 100 000 pokusů

Takže moje metoda zdrží útočníka cca 25x déle než ta tvoje metoda a cca 70x déle než pouhé jedno md5()...

Jediné špatné úskalí by mohlo být při generování toho hashe. Například při registraci na fóru, e-shopu aby nemusel čekat zákazník 7 sekund než se mu odešle registrace...
Řešení:
1) zregulovat to z 1000x md5() třeba jen na 100x md5(), což i tak bude několikanásobně lepší než jiné možnosti...
2) začít generovat hash hned při vepsání hesla skrz javascript/ajax od input boxu. Začal bych generovat hash po události onBlur, až nastane u našeho pole.
3) v případě velkého trafficu můžeme například omezit registrace tím, že admin na oko zkontroluje účet a ručně ho zaktivuje s tím, že to bude následující pracovní den. Heslo tedy nemusíme hashovat rovnou, ale můžeme si ho uložit v plaintextu do db a třeba někdy ve 3-4 ráno projet skrz cron všechny plaintexty a převést je na požadovaný tvar. Možná krkolomné řešení, ale teď mě to jen tak napadlo... Taky by to šlo...

Nějaké lepší řešení?


Co říkáš na ty výsledky?

Jsem se trošku rozepsal... To jsem rovnou mohl napsat článek na toto téma! :-D
(odpovědět)
Shaim25.8.2011 2:35
re: Bezpečně uložená hesla v db - hashování#
Vubec bych nevidel problem v tom, ze registrace bude trvat 7 vterin. Staci vypsat hlasku "Pockejte prosim.." a hodit tam nejakou grafickou blbost, ktera da uzivateli pocit, ze "to neco dela".

Mnohem horsi by to bylo s prihlasovanim, kdy by chudak uzivatel opet cekal 7 vterin a to uz by mohl byt opravdu problem.

Dalsi problem je v tom, ze najit kolizni retezec k MD5 hashi je otazka cca dvou vterin, tzn. ze na vygenerovani retezce, kterym by se utocnik mohl prihlasit, je otazka mene nez 40 minut (uz se mi chce spat a mam v sobe par piv, tak mozna kecam, ale imho to tak je). Samozrejme je to podminene tim, ze utocnik zjisti zpusob, jakym se hash generuje..

Ono za predpokladu, ze utocnik zjisti, jakym zpusobem se hash generuje, je stejne celkem pravdepodobne, ze se v aplikaci budou nachazet i jine zavazne chyby, takze s timhle bych si nedelal takove nasili a pouzil neco jako Emkei.
(odpovědět)
independent_ | 109.80.59.*25.8.2011 3:46
re: Bezpečně uložená hesla v db - hashování#
Emkeiův způsob se mi také líbí (zejména to zkrácení sha1 na délku, aby to vypadalo jako md5()).

Jistě, na přihlašování jsem úplně zapomněl... Taky by se tam musela dát nějaká grafická blbost, jak jsi to nazval :) A když si tak vzpomínám, tak občas na webech, když se přihlašuji, tak čekám třeba 3-4 vteřiny, takže by to zase nebyl takový problém.

Dobře, dejme tomu, že by útočník zjistil, jak se generuje hash... Jak díky tomu vytvoří kolizi? Nějaký link?
(odpovědět)
Shaim25.8.2011 16:50
re: Bezpečně uložená hesla v db - hashování#
Je to 30s, ne 2 vteriny, jak si myslel: [link] Tim padem by nalezeni kolize trvalo 30 000 vterin, coz je cca 8,3 hodiny a to uz je dost.

Myslim, ze by stacilo najit kolizi k poslednimu MD5 hashi (tomu v databazi), kolizni retezec zahashovat, najit k nemu dalsi kolizi, zase zahashovat atd., az by se po tisici iteraci utocnik dostal k retezci, ktery kdyz se 1000x zahashuje algoritmem MD5, vysledkem bude stejny hash, ktery je ulozeny v databazi, ale mozna se pletu.

To prihlasovani by mohl byt velmi vazny problem u navstevovanejsiho webu, kde by mohlo vytizeni serveru narust na neunosnou mez. Resit by se to mozna dalo tak, ze by se heslo zahashovalo uz u klienta treba pomoci Javascriptu, ale s tim vystavaji tyto problemy:
a) uzivatel nemusi mit Javascript povoleny
b) uzivatel muze mit slabsi PC (pripadne mu muzou bezet dalsi narocne programy), coz muze mit za nasledek vytizeni procesoru na 100% a mozna i pad prohlizece

Premyslel jsi treba nad pouzitim nejake mene zname hashovaci funkce? Mohl by jsi ji v PHP implementovat sam, aby cela aplikace nebyla zavisla na dalsi knihovne. Kombinace nekolika hashovacich funkci by mela naprosto dostacovat.

Velmi zajimave by mohlo byt vytvorit v databazi napriklad 6 sloupecku pojmenovane Password1, Password2, Password3 atd. Vysledny hash hesla by se pote rozdelil napr. na 2 stejne dlouhe casti, pricemz ty by byly umisteny pouze ve dvou sloupcich, zbyle ctyri sloupce by se naplnili nahodnymi daty, ktere budou mit uplne stejny tvar a format, tj. utocnik nepozna, z ceho je vlastne hash slozen. Do kterych sloupcu (1 az 6) se obe casti hashe ulozi by pritom mohlo byt rozhodnuto napr. na zaklade nektereho pismena v loginu, case registrace (samozrejme by musel byt take ulozen), ID uzivatele apod.

Utocnik, ktery by mel pouze pristup do databaze nema sanci zjistit, z jakych casti je vlastne hash hesla slozen. U kazdeho uzivatele by navic spravny hash hesla byl ulozen v jinych sloupcich. Utocnik by se pak tedy musel dostat ke zdrojovym kodum (byla by to jedina jeho sance) a zjistit, jakym zpusobem se hashe ukladaji / nacitaji. Je zde ovsem urcita sance, ze to nepochopi ani se zdrojovymi kody, zvlast v pripade, ze bude kod prohnany nejakym obfuskatorem a zasifrovany treba pomoci base64.

Pokud jsi tedy opravdu paranoidni, zkus pouzit neco takoveho, myslim, ze je to mnohem lepsi, nez 1000x hashovat pomoci MD5..
(odpovědět)
independent_ | 109.80.59.*25.8.2011 18:02
re: Bezpečně uložená hesla v db - hashování#
tady pozor, pres databazi je mozne cist i soubory na disku, coz plati pro drtivou vetsinu webhostingu, takze toto vicemene (spis vice) neplati...
(odpovědět)
Emkei | E-mail | Website | PGP25.8.2011 23:01
re: Bezpečně uložená hesla v db - hashování#
Souhlas... zkoušel jsem toto nedávno na pár zahraničních webhostinzích(free) a myslím, že kromě jednoho to šlo u všech... (Bylo jich asi 8)

Avšak nemyslím si, že na placených by byl výsledek razantně odlišný...
(odpovědět)
Shaim26.8.2011 3:51
re: Bezpečně uložená hesla v db - hashování#
Tak v tom pripade by to chtelo pouzit hodne kvalitni obfuskator, ale to uz je o nicem. Utocnika to muze maximalne zdrzet..

Hadam, ze moznost cist pres databazi soubory by se musela vypnout v konfiguraci, ke ktere ma pristup pouze root. Neslo by tedy alespon chmodnout svoje soubory tak, ze databaze nebude mit pravo je cist?
(odpovědět)
independent_ | 109.80.59.*26.8.2011 13:36
re: Bezpečně uložená hesla v db - hashování#
ten chmod muze pomoci, ale nemusi, opet zalezi na konfiguraci serveru.
(odpovědět)
Emkei | E-mail | Website | PGP27.8.2011 6:07
re: Bezpečně uložená hesla v db - hashování#
Problém dlouhého výpočtu na straně serveru je v tom, že ti tak můžou zdosit server. Stačí jen posílat velké množství požadavků na přihlášení.
(odpovědět)
Bystroushaak_ | 83.208.175.*25.8.2011 19:44
re: Bezpečně uložená hesla v db - hashování#
To je taky pravda, ale to by se na druhou stranu dalo nejak omezit (povolit jen urcity pocet prihlaseni / reigstraci za hodinu atp). Ale stejne je lepsi to moje reseni :D
(odpovědět)
independent_ | 109.80.59.*25.8.2011 19:53
re: Bezpečně uložená hesla v db - hashování#
Jak jsem psal, tak ten příklad 1000x md5() byl jen ilustrační. Bylo by s tím určitě dosti problémů a jak jsem již psal několikrát, tak řešení, které uváděl Emkei se mi líbilo nejvíc.

Jak píše Bystrouhak, tak na straně serveru by to určitě nebylo dobré za předpokladu, že by to byl nějaký větší server. Na druhou stranu výpočty na straně klienta by vyžadovali zapnutý js nebo je jiná metoda? Každopádně... Kolik lidí má vypnutý js?

Odhadem tak 5% s tím, že 1% jsou lidé, kteří k vypnutí JS mají své důvody a 4% spam boti :-P
(odpovědět)
Shaim25.8.2011 20:45
re: Bezpečně uložená hesla v db - hashování#
Jen taková šaškárna [link] na jednu větičku !


Zkoušel jsem heslo o délce 4 znaky nějakým způsobem rozluštit, ale bez úspěchu, to snad ani nejde, ne?


Také mám svou šanci být občas nějakým útočníkem :)
(odpovědět)
Drbalka | 80.237.226.*25.8.2011 22:42
re: Bezpečně uložená hesla v db - hashování#
No, ale to, co ty ukazuješ jsou hashe, které byly generované pouze klasicky, tzn 1x md5()...

My jsme zde začali debatu s tím, že projedeme string 1000x md5(), což je lehce odlišné...

(odpovědět)
Shaim26.8.2011 3:38
re: Bezpečně uložená hesla v db - hashování#
Jo, pěkné náročné řešení. Oni správci docela často prostě ani nezahashují, sle mám odněkud za několik, které jen tak prohledat nejdou.


account_type ADMIN
account_name Administrator account
m2m_password ey$GpHqwfO6PZ7QW^BpmVS!#b
m2m_ticket

account_type MANAGER
account_name Default manager
m2m_password OInJnf(wjv*vA#&qkSCK$UcDU
m2m_ticket w_EbF-Pe)5Sqm6RNXyu3gn4CNnM2((



pass=$S$CfNS08DxxjoeWXBHS1cxnDK42TbMOxn0cyV
paYNwvRClnZwou9QZ
pass=$S$Cyh6ds6QwFVOLHWxlK.uXazvHqfYKdnDlSj
Lw3r3Q1A2VO16RgAq

Po tomhlr by kdekoho to crackování asi přestalo bavit :)
(odpovědět)
Drbalka | 77.247.181.*26.8.2011 15:52
re: Bezpečně uložená hesla v db - hashování#
No, tak klasické řešení je udělat něco jako:

nick = "nickname"
email = "e@ma.il"
passwd = "heslo"

hash = sha1(md5(nick) + sha1(email) + passwd)

Tedy že použiješ jako salt další uživatelské informace, které stejně v databázi musíš mít uložené. Tím úplně vyřadíš rainbowtables.
(odpovědět)
Bystroushaak_ | 83.208.175.*26.8.2011 17:13

Zpět
 
 
 

 
BBCode