php+enkripcija gesla

Jst ti vsekakor svetujem, da uporabiš že obstoječo, neko preverjeno varjanto, ki je dovolj zanesljiva in dobra.

base64_encode(hash('whirlpool', $salt . $password, true))

velikost stolpca v bazi mora biti potem 88 znakov.

hash('whirlpool', $salt . $password, false)

velikost stolpca v bazi mora biti potem 128 znakov.

Recently, a number of projects have created MD5 rainbow tables which are easily accessible online, and can be used to reverse many MD5 hashes into strings that collide with the original input, usually for the purposes of password cracking. However, if passwords are combined with a salt before the MD5 digest is generated, rainbow tables become much less useful.

Če originalni string "posoliš" predno ga kodiraš z MD5, je v 99% primerih to dovolj dobra zaščita. Pri večini PHP aplikacij je način shranjevanja gesel manjši problem od ostalih lukenj nepazljivih programerjev, konec koncev, če nekomu uspe vpogledat v bazo, kjer so shranjeni hashi, je precej verjetno da si je uspel pridobit vpogled v še kaj drugega.

Eh ja PHP. Imas hash(), md5(), crypt() pa najbrz se kaj tretjega. Hash in md5 se meni zdita bolj uporabna za racunanje hashov nekega teksta kot pa za gesla, jasno pa da jih lahko vseeno uporabis. V primeru podpisovanja dokumentov je pa res za odsvetovati MD5. Crypt() po drugi strani je bolj samo kot wrapper za iz UNIX-a poznan crypt(), kar torej omogoca neko kompatibilnost med s PHP generanimi izvlecki gesel in sistemski gesli. Druga prednost je, da v prvem primeru salt sam dodajas k stringu, medtem ko ima crypt() parameter salt in je vse skupaj bolj clean.

Za kakšno osebno uporabo je md5 popolnoma ok.

Tukaj ne gre za osebno ali poslovno rabo, ampak za to kje se MD5 uporablja. Recimo kot one-way hash passworda je za enkrat (in verjamem da tudi v bliznji prihodnosti) MD5 se cisto OK. Problem pa je recimo digitalno podpisovanje. Digitalni podpis je z zasebnim kljucem sifriran izvlecek originalnega dokumenta. Ok recimo, da ti nekdo da PDF z neko pogodbo, ki jo elektronsko podpises. Tezava je v tem, da naceloma ne ves, ce nima ta nekdo mogoce se enega PDF-ja z istim hashom, kjer pise nekaj popolnoma drugega. Tvoj podpis pa avtomaticno velja za oba dokumenta (ker je na podlagi izvlecka oboje eno in isto).

Prej sem rekel, da ni mogoce za poljuben dokument ustvariti drugega dokumenta z istim hashom. Ampak istocasno ustvariti 2 razlicni datoteki z istim hashom je pa cisto mogoce.

V bistvu najprej ustvaris dve razlicni random datoteki (collision). Karkoli dodas za ta random junk v obeh datotekah bo se vedno ohranilo isti hash. Fora zdaj je samo, da se tisti drug del nekako navezuje na zacetek in v primeru, da je dolocen bit 1 naredis nekaj, sicer pa nekaj drugega. Nekako naredis se, da si tisti zacetek ne vidi pa je.

Napadalcem je uspelo celo, da je CA s podobnim "trikom" podpisal lazen X.509 certifikat. Jasno, da bi se v zahtevku videlo ze na dalec, da nekaj ni OK. Samo kaj, ko so avtomatsko podpisovali zadeve.

Torej tudi za podpisovanje je MD5 se vedno OK, pod pogojem, da ima uporabnik nekaj common-sensa in podrobno preuci kaj podpisuje. Ce gres gledati npr. s hexeditorjem PDF bos lepo videl obe verziji dokumenta. V kolikor si preprican o tem, da te tisti, ki ti je dal datoteko v podpis ne nateguje, z MD5 naprej ni vec nobenega problema.

Najbolj enostaven workaround je pa to, da naredis majhen oblikoven popravek na dokumentu, ki ga podpisujes, kar spremeni hash in ga sele potem podpises. Tako postane tista druga verzija, ki jo ima potencialen napadalec v zepu takoj neuporabna.

Zdravo

Imam eno vprašanje glede tega salt sistema. Trenutno imam v bazi gesla zakodirana samo z md5 funkcijo in sedaj želim izboljšati varnost. Zdaj pa me samo zanima, če zadevo prav razumem.

Torej ko se uporabnik npr. registrira na moji strani, se mu dodeli nek naključen, 10 znakov dolg "salt" in tega shranim v bazo brez, da je kodiran. Istočasno v bazo shranim tudi celoten "hash" - md5($10znakovdolgsalt.md5("vpisanogeslouporabnika"))

In potem, ko se želi uporabnik naslednjič prijavit, iz tabele poberem ti dve polji (salt, hash) in preverim na spodnji način.

$vpisano_geslo = md5($salt.md5($_POST["geslo"]));

if($vpisano_geslo == $hash) { // ustvari sejo }

Je to pravilen način?

Hvala in lp,
Housy

Jaz bi načeloma raje uporabljal crypt() namesto md5(). Pri crypt() je geslo zapisano v standardnem zapisu $alg$salt$hash - pri čemer je alg oznaka algoritma, salt nek naključen string in hash one-way-hash kombinacije salta in plain-text gesla (nekateri algoritmi uporabljajo še več z $ ločenih polj). Salt se uporablja samo zato, da se npr. če imata dva uporabnika isto geslo, to ne preslika v isto vrednost (kar naredi rainbow table napade neuporabne).

Prednosti je več:
- crypt() je neke vrste standard, kar pomeni, da boš lahko generiral ustrezen zapis z raznoraznimi tooli, uporabil obstoječa UNIX gesla itd.
- geslo enega uporabnika bo lahko shranjeno z uporabo Blowfish, drugo z MD5 itd. pa bo še vedno vse delovalo, drugače boš moral sam skrbeti za združljivost (predvsem za nazaj, ko enkrat ne boš hotel več uporabljati samo MD5)
- v bazi boš imel samo eno polje za geslo, ne salt posebej in ne vem kaj še vse
- crypt() z $1$ še vedno ni samo direktno MD5 vhoda, ampak je načrtovan tako da pokuri malo več CPU ciklov (tako da je potem pri bruteforcanju manj poskusov na sekundo)

Example #1 na prej omenjeni strani je lep primer uporabe, ki bi se ga držal.

Zakaj bi karkol pisal kamorko.ce hoces bit cist paranoja d.o.o....lepo uporabi hardware info z masine(mrezna,disk...maticna) pa je.Tle mas potem se zmer optimizem, da mogoce dobi samo readyonly access in samo vidi kodo...ki si jo se lahko se zmeraj vtakne v rit brez write accessa do masine :)

Needless to say si zadevo se zmer nekam zapises(recimo PAPIR)...ce slucajno kksna komponenta crkne :)