Hašování hesel

HackForum

Hašování hesel#
jak by podle vas mela vypadat funkce/metoda slouzici k bezpecnemu ukladani hesel v databazi (za predpokladu, ze nemate k dispozici knihovnu mhash)? osobne bych to resil nasledovne, ale rad si necham poradit:

__________

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

return $hash;
}
__________


promenna $login slouzi jako salt zabranujici situaci, kdy by melo vice uzivatelu se stejnym heslem v databazi totozny hash.

promenna $token je nahodne vymyslena konstanta slouzi rovnez jako salt, v tomto pripade vsak zabranuje situaci, kdy by vice uzivatelu se stejnymi prihlasovacimi udaji melo na serverech vyuzivajici tento algoritmus stejny hash (za predpokladu, ze je na kazdem z techto serveru administratory nastaven jiny token).

hasovaci funkci sha1() jsem uprednostnil pred md5() z toho duvodu, ze je z hlediska bezpecnosti stale vhodnejsi variantou.

jelikoz jsou v dnesni dobe k dispozici rozsahle rainbow tabulky, dochazi k hashovani dvakrat za sebou, cimz by mel tento problem odpadnout. v pripade, ze by se objevila rainbow tabulka s double-sha1 hashi, lze tento proces doplnit o dalsi iteraci/iterace.

v zaveru dochazi ke zkraceni hashe ze 40 znaku na 32, a to ze dvou duvodu. pokud se z nejakeho duvodu nezverejni spolecne s databazi i pouzity algoritmus (napr. pri SQL Injection), crackeri se budou mylne domnivat, ze se jedna o md5 hash. pokud bude spolecne s hashi kompromitovan i pouzity algoritmus, pak si presto musi utocnik diky tomuto zkraceni napsat vlastni cracker, nebot v dostupnych crackerech takovy hash neprolomi.

navrhy? vytky? pripominky? =)
(odpovědět)
Emkei | E-mail | Website | PGP17.3.2008 20:37
re: Hašování hesel#
Heh celkem paranoia :P To zkracovani je dobrej napad, to se bezne pouziva? btw nemam co dodat :P

----------
*´¨)
¸.·´¸.·´¨)
(¸.·´ (¸.·*´`*·>>> [link] <<<
(odpovědět)
|/V/=|/V|7`/ | E-mail | Website17.3.2008 20:40
re: Hašování hesel#
zas tak paranoidni to neni, navic kdyz to zabira jen 3 radky a v porovnani s klasickym
$hash = md5($heslo);
je to mnohonasobne bezpecnejsi, tak proc ne? =)
(odpovědět)
Emkei | E-mail | Website | PGP17.3.2008 20:43
re: Hašování hesel#
sha1(md5(base64_encode('bla'.$login.'bla'.$
pass.'bla')))

ja nevim me fakt nic nenapada :D:D, ja pouzivam md5(md5(md5($pass))), nebo mozna jen 2x md5, sma nevim...

----------
..:@]> [link] <[@:..
(odpovědět)
DjH | E-mail | Website | ICQ 319-960-89517.3.2008 20:52
re: Hašování hesel#
nvm, ale neni vicekrat hashovani md5 = vice kolizi? Nekde jsem o tom videl pojednavat nejakej clanek..

----------
Cow power by Gentoo...
(odpovědět)
Anonymous_ | E-mail18.3.2008 16:55
re: Hašování hesel#
jo a btw, to substr, zkracovani hashu, to znam, je to dost dobra oblbovacka... Vystupni hash sha1 zkracen na 32 znaku je celkem k nerozeznani od hashe md5... az na samotny vyflus hashe no...

----------
..:@]> [link] <[@:..
(odpovědět)
DjH | E-mail | Website | ICQ 319-960-89517.3.2008 20:56
re: Hašování hesel#
Já osobně používám

Base64_Encode(MD5(Base64_Encode($heslo)))

Pro Base64_Encode() sice existuje dekódovací metoda ale:

(Jako heslo je použito heslo)

1.) Text se zakóduje pomocí Base64_Encode()
Base64_Encode("heslo") = aGVzbG8=

2.) Heslo se zakóduje pomocí MD5()
MD5("aGVzbG8=") = 38c8fa1328b249cb997392dd3d2e83c2

3.) Heslo se zakóduje pomocí Base64_Encode()
Base64_Encode("38c8fa1328b249cb997392dd3d2e
83c2") = MzhjOGZhMTMyOGIyNDljYjk5NzM5MmRkM2QyZTgzYzI
=

Pokud toto znova zakóduju do MD5, vznikne toto:
424ff991dfac513ac59d1ce0ddd8538b

A obávám se, že takovýto řetězec v žádné Rainbow Table nenajdeš :)
(odpovědět)
Nazghul | E-mail | Website | ICQ 23636583617.3.2008 21:04
re: Hašování hesel#
Pokud si zvolíš nějaké složitější heslo, tak už ten první převod bude delší a crackování MD5ky bude těžší...
(odpovědět)
Nazghul | E-mail | Website | ICQ 23636583617.3.2008 21:08
re: Hašování hesel#
IMHO je blbost 2x hashovat. Rychlost, hashovani retezcu o stejne delce. Narazis na problemy s dalsimi aplikacemi, ktere pracuji se stejnymi daty... novy system...
Proc pouzivat predem definovy salt? Generuj nahodny a uloz jej v databazi... Kdyz to bude chtit nekdo cracknout, tak bude pro kazdy zaznam muset generovat nove rainbow tabulky...
Takze ten login je taky zbytecnost ;] S "nahodnym" saltem nedostanes dva stejne hashe.
Orezani hashe? blbost. Kazdy rozumny clovek si nejdriv do systemu vlozi svoje data, takze si stejne zjisti ze to MD5 neni ackoliv to tak muze vypadat.
Jdi cestou nejmensiho odporu a nedelej si _zbytecne problemy_. Pritvrd bezpecnostni politiku pri volbe hesla. Vygeneruj nahodny retezec + heslo. A to JEDNOU hashuj...




(odpovědět)
HC17.3.2008 21:29
re: Hašování hesel#
vicenasobne hasovani podle me blbost neni, duvod jsem vysvetlil uz v uvodu a problem s jinymi aplikacemi nebo novym systemem jsem eliminoval tim, ze jsem pouzil standardni hasovaci funkce a vyhnul se knihovne mhash.
k cemu slouzi prvni i druhy salt jsem rovnez popsal, zbytecne mi rozhodne neprijdou, stejne tak vyhody orezani hashe. utocnik se vetsinou dostane pouze k hashum, nikoliv vsak k pouzitemu algoritmu (pres SQL Injection) a na ten v podstate nema sanci prijit, nebot jako posledni hashovaci funkci bude vzdy zkouset algoritmus md5.

jestli jsem te spravne pochopil, resil bys problem hasovani hesel v databazi napr. s desetiznakovym saltem nejak nasledovne:
__________

function CreateHash($password) {
$salt = md5(uniqid(mt_rand(), true));
$salt = substr($salt, 0, 10);
$user['salt'] = $salt;
$user['hash'] = sha1($salt.$password);

return $user;
}

__________

osobne bych mel s timto resenim problem v tom smeru, ze bych musel navic vedle prihlasovacich udaju kazdeho uzivatele ukladat v databazi jeste ten desetiznakovej salt, coz mi prijde ponekud neefektivni, nemluve o tom, ze jsme nikterak nezabranili pripadnemu utocnikovi ve vyuziti rainbow tabulek nebo crackeru.
(odpovědět)
Emkei | E-mail | Website | PGP18.3.2008 11:40
re: Hašování hesel#
V dobre navrhnute databazi a dobrem kodu by nemel byt zadny problem pridat dalsi sloupec se saltem. A efektivita tim nijak neutrpi ;] Ale klidne muzes pouzit login jako salt -> zadne dalsi sloupce.
Ale porad si stojim za tim, ze dvojnasobne hashovani je zlo a je mene bezpecne, nez jednou hashovany retezec. Dochazi totiz k hashovani 40ti znakoveho retezce slozeneho pouze ze znaku [0-9a-f]. Kdyz to nasledne jeste zkratis na 32znaku, tak vznika relativne velke mnozstvi koliznich retezcu (ackoliv sance na zjisteni hesla je mensi).
Zbytecne si to nekomplikuj. Pouzij silnejsi hashovaci algoritmus. Treba sha512 ;], ktery je v PHP5 ve funkci "hash" a trvej na dobrych uzivatelskych heslech.
"nemluve o tom, ze jsme nikterak nezabranili pripadnemu utocnikovi ve vyuziti rainbow tabulek nebo crackeru." -- Zabranili. Protoze kazdy zaznam v DB bude mit jiny salt. A ikdyz ho bude znat, tak musi pro _kazdy_ hash vygenerovat nove RB tabulky. Nemuze jednu pouzit pro vsechny hashe, neb kazdy obsahuje jiny salt.


(odpovědět)
HC18.3.2008 18:05
re: Hašování hesel#
nejde o to, ze by to byl problem, spis mi to opravdu prijde neefektivni, kdyz promenna $login zajistuje v podstate to same.

"Ale porad si stojim za tim, ze dvojnasobne hashovani je zlo a je mene bezpecne, nez jednou hashovany retezec."

to myslis vazne, nebo me chces nastvat? =) zkus se na chvili vzit do role utocnika a cracknout jak mnou, tak tebou navrzeny algoritmus a uvidis ten rozdil. zatimco v tvem pripade, pokud budeme uvazovat striktni pravidla pro tvorbu hesla (tedy minimalne 8 znaku dlouhe a dostatecne barevne), pak v tom nejidealnejsim pripade musi utocnik prekonat heslo slozene z 18 znaku obsahujici az 62 ruznych symbolu [a-zA-Z0-9]. za takove situace musi vyzkouset na 183 x 1030 kombinaci. v mnou navrhovanem algoritmu musi utocnik v kazdem pripade ziskat pro dalsi postup hash slozeny ze 40 znaku obsahujici az 16 ruznych symbolu [a-f0-9]. za techto podminek musi vyzkouset na 146 x 1046 kombinaci, coz je o 16 radu vic, tedy mnohonasobne narocnejsi operace. navic pokud se v tvem pripade podari k hashi priradit odpovidajici retezec, pak je utocnik u cile, zatimco v mnou navrhovanem reseni ziska hned nekolik retezcu (hashu), ktere maji po druhem pruchodu funkci sha1() prvnich 32 znaku stejnych, pricemz nema sanci zjistit, ktery z techto retezcu (hashu) je ten spravny. pokud by chtel utocnik presto v crackovani pokracovat, musel by dale pro kazdy hash z tohoto mnozstvi vyzkouset v nejidealnejsim pripade az 769 x 1024 kombinaci!

jeste porad ti pripada, ze vicenasobne hashovani a zkracovani hashe algoritmus oslabuje?
(odpovědět)
Emkei | E-mail | Website | PGP18.3.2008 21:56
re: Hašování hesel#
IMHO je tvoje varianta lepší... Myslim že pokud nejsi vyloženě paronoidní nebo nečekáš opravdu velmi vysoký počet lidí(nebo člověka se supercomputerem a pár volnými PB na disku), kteří se v oboru orientují a budou chtít tvuj hash prolomit, tak ti to bude stačit...

----------
Punk will never be dead to me. It's my life. I can never just drop this lifestyle. It embodies me.
(odpovědět)
|>011'/ | E-mail18.3.2008 23:04
re: Hašování hesel#
Nechci te nastvat. ;p To co jsi napsal je pravda. Ale ja netvrdil, ze to tak neni ;D "vznika relativne velke mnozstvi koliznich retezcu (ackoliv sance na zjisteni hesla je mensi)". Rekl jsi to stejne co ja, jen jinymi slovy...

Tim, ze je to mene bezpecne jsem myslel:
"Ze 160ti bitoveho vstupu vznikne 160ti bitovy vystup, tudiz na bezpecnosti to neprida. Naopak se tim zvysi sance na nalezeni _nejakeho_ kolizniho retezce, ktery produkuje stejny dvojity-hash". Ano, vim, ze kolize bude utocnikovi celkem k nicemu, kdyz potrebuje vedet heslo, ale kdo vi, jestli to nebude treba v budoucnu uzitecne ;]
Proste pro me takove reseni neni ciste a nepouzil bych ho (stejne jako bych si do auto nedal dva stejne zamky [bezpecnost by to nezvysilo, pridelalo to dost problemu, a jeste by to vypadalo blbe]). Ale kazdemu dle libosti... Kdyz uz bych chtel byt paranoidni, tak radeji sahnu po silnejsim hashovacim algoritmu...

(odpovědět)
HC18.3.2008 23:31
re: Hašování hesel#
rad bych sahnul po silnejsim hashovacim algoritmu, jenze tim prijdu o stoprocentni prenositelnost na jine servery, coz se napr. v pripade zakazek, kde predem nevis, na jakych serverech vytvareny system pobezi, moc nehodi.
uzavrel bych to asi v tom smyslu, ze neexistuje jedine spravne reseni - kolik lidi, tolik chuti, pricemz kazdy by pouzil takovy algoritmus, ktery by podle jeho presvedceni "vypadal v jeho aute nejlepe" =)
(odpovědět)
Emkei | E-mail | Website | PGP19.3.2008 0:01
re: Hašování hesel#
imho na téměř nerozhashovatelný postup stačí (obecně):

$hash = hashovaci_fce($heslo);
$hash = jednoduchá_transpoziční/substituční_šifra($
hash,$login);
$hash = hashovaci_fce($hash);

:-)

----------
Get enlightened!
(odpovědět)
mr.Crow | E-mail | Website17.3.2008 21:29
re: Hašování hesel#
na tvem reseni se mi prozmenu nelibi fakt, ze bych si kvuli ukladani hesel musel navic napsat algoritmus transpozicni nebo substitucni sifry, pripadne pokud bych chtel vyuzit vedle hasovacich i dostupne sifrovaci funkce, ztratil bych tak stoprocentni prenositelnost kodu.
(odpovědět)
Emkei | E-mail | Website | PGP18.3.2008 11:40
re: Hašování hesel#
klidně lze použít base64, nahrazení prvních tří písmen hashe prvním, druhým a posledním písmenem loginu...stačí něco naprosto jednoduchého.

----------
Get enlightened!
(odpovědět)
mr.Crow | E-mail | Website18.3.2008 17:39
re: Hašování hesel#
K tomu zkracování hashe. Nemůže s v praxi stát, že by se uživatel mohl přihlásit s více různými hesly?
(odpovědět)
Profik123 | E-mail | Website | PGP | ICQ 342-453-21418.3.2008 13:38
re: Hašování hesel#
tebou popisovana situace by nastala az tehdy, kdybychom ten hash orizli opravdu rapidne. my jsme ho vsak zkratili na velikost md5 hashe, tim padem by byl pripad, ze by se uzivatel mohl prihlasit s vice ruznymi hesly, asi tolik pravdepodobny, jako ze najdes pro heslo hashovane pomoci funkce md5() jine pouzitelne heslo se stejnym hashem, coz je (v soucasne dobe) nemozne.
(odpovědět)
Emkei | E-mail | Website | PGP18.3.2008 14:16
re: Hašování hesel#
Tak jak to máš je to podle mě dostatečně bezpečný.
Při ukládání hashů do databáze lze šetřit místo přidáním druhého parametru funkci sha1 na true, funkce ale bude mít binární výstup, tak v databázi musí být nastavený binární datový typ.
(odpovědět)
nejmenuje -unlogged | 212.71.186.*18.3.2008 14:50
re: Hašování hesel#
Emkei je proste master....
(odpovědět)
Shaiiiiiii | 81.92.146.*28.3.2008 4:05
re: Hašování hesel#
Noo IMHO (=)) to viac nasobne hashovanie je vcelku dostacujuce. Nahodny pocet hashovania popripade pouzivanie viacerych hashovacich funkcii oblbne rainbow tabulky a pokial je velky pocet hashovania hesla tak to moze spomalit brutus na tolko ze cracknut vysledny hash bude nerealne... A pokial sa niekomu zda neefektivne mat v tabulke este niaky udaj naviac ako napriklad kolko krat je zahashovane heslo tak to cislo sa da skontruovat aj nejak na zaklade nicku co zabbezpeci ze pocet hashovania bude vzdy iny.
(odpovědět)
Zzzz | 193.93.72.*28.3.2008 15:18
re: Hašování hesel#
proc je skoro polovina slovaku zavisla na programech typu Brutus?? Kdo to tam rozsiruje omg?

----------
..:@]> [link] <[@:..
(odpovědět)
DjH | E-mail | Website | ICQ 319-960-89528.3.2008 16:01
re: Hašování hesel#
2DjH: Noo akoze neviem jak si z tohto dosiel na to ze som (alebo sme) zavisly na brutuse? len hovorim ze tou metodou sa mozes zbavit rainbox tabuliek a znepriemnit (alebo znemoznit ) brutus...
Tak neviem co ty robys ked narazis na md5-ku ktoru potrebujes craknut ale ja väcsinou skusam rainbow, brutus alebo dictationary.
(odpovědět)
Zzzz | 193.93.72.*28.3.2008 18:48
re: Hašování hesel#
vole, ja se snazim rict ze brutus je dnes nemozny sam o sobe. S brutusem nic nedokazes

----------
..:@]> [link] <[@:..
(odpovědět)
DjH | E-mail | Website | ICQ 319-960-89529.3.2008 12:58

Zpět
Svou ideální brigádu na léto najdete na webu Ideální brigáda
 
 
 

 
BBCode