» »

php+enkripcija gesla

php+enkripcija gesla

alexxxx ::

Lep pozdrav!

Zanimajo me vaši predlogi kako naj zakodiram geslo, poznam nekaj metod vendar nevem katera je najučinkovitejša, najprej sem mislil uporabit md5 vendar sem ugotovil da so jo že razbili.

Naj napišem svojo funckijo ali uporabim že katero obstoječo?

Že vnaprej se zahvaljujem za odgovore.

FlashM ::

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

fiction ::

Naj napišem svojo funckijo ali uporabim že katero obstoječo?
Ce mislis sam izumljati kriptografske algoritme je verjetnost nekje 99%, da bos stvar zelo zafrknil.

Zanimajo me vaši predlogi kako naj zakodiram geslo, poznam nekaj metod vendar nevem katera je najučinkovitejša, najprej sem mislil uporabit md5 vendar sem ugotovil da so jo že razbili.
Jaz bi uporabil enostavno crypt npr. z Blowfish algoritmom.
Samo toliko da razscistimo: MD5 NISO razbili. Odkrili so, da je mogoce prakticno izracunati dva cudna vhoda, ki vrneta isti MD5 hash (collision). Niti ne tako, da bi za tocno dolocen vhod lahko izracunal nekaj z istim hashom. Pa se to je zelo dalec od tega, da MD5 ne bi bil vec uporaben kot one-way-hash algoritem za geslo in bi npr. iz hasha lahko dobil password.

Drugace pa pri passwordih ponavadi isces najbolj NEucinkovito (a varno) metodo, kajti to lahko upocasni razne bruteforce napade.

krho ::

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.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

Zgodovina sprememb…

  • spremenil: krho ()

urosz ::

kaj pa sha1?

680x0 ::

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.

dbevfat ::

Uporabi hashing, npr. sha, tudi md5 je za silo ok. Obvezno uporabi sol. Ne zafrkavaj se z enkripcijo, ker napadalec potrebuje samo ključ in pride do plain-text gesla, česar pri hashih ne more narediti.
nvr2fat

fiction ::

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.

blackbfm ::

Za kakšno osebno uporabo je md5 popolnoma ok.

fiction ::

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.

Zgodovina sprememb…

  • spremenil: fiction ()

blackbfm ::

Ne glede na vse je še vedno ekstremno malo možnosti da bi se kdo spušču v to...razen če gre za kakšne zanimive dokumente.

Housy ::

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

Zgodovina sprememb…

  • spremenil: Housy ()

Housy ::

Ali je morda vseeno bolje, če uporabim vedno enak salt in ga imam shranjenega recimo v eni php datoteki (npr. salt.php)?

Ker če mi nekdo vdre v bazo, potem bo videl tudi salt, ampak res pa je, da pa mora ugotovit, kakšen algoritem uporabljam. To pa itak ne more videt, če nima dostopa do datotek na strežniku.

Tnx, Housy

fiction ::

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.

fiction ::

Housy je izjavil:

Ali je morda vseeno bolje, če uporabim vedno enak salt in ga imam shranjenega recimo v eni php datoteki (npr. salt.php)?
Samo en salt pomeni isto kot če salta sploh ne bi imel. Salt mora biti vsakič (npr. tudi če uporabnik spremeni geslo) naključno zgeneriran.

Če predpostavljaš, da ti nobeden ne bo vdrl v bazo, imaš lahko shranjena tudi plain-text gesla. Ampak poanta je ravno v tem, da dopustiš možnost, da te nekdo sheka (in takrat bo dobil tudi salt.php).

Sicer je to slaba praksa, ampak uporabnik Janez npr. lahko uporablja isto geslo za več storitev. Ko je ena od teh (recimo tvoja) tarča vdora in nekdo pridobi shranjena gesla, nočeš, da bo napadalec direktno videl kakšno je Janezovo geslo, ker bi s tem lahko zlorabil uporabniški račun še drugje. Seveda napadalec lahko s kompromitiranjem strežnika spremlja plain-text gesla, ki pridejo po mreži, ampak to je še vedno bolje kot če dobi direktno vsa gesla na pladnju.

Looooooka ::

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 :)

Zgodovina sprememb…

  • spremenilo: Looooooka ()

Housy ::

Hvala za obrazložitve :)

Zgodovina sprememb…

  • spremenil: Housy ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

java in mysql -> preveri geslo

Oddelek: Programiranje
6784 (634) Goldee
»

Analiza slovenskih gesel

Oddelek: Novice / Zasebnost
399507 (7445) BlueRunner
»

Manj znane varnostne ranljivosti PHP programske kode

Oddelek: Novice / Varnost
313722 (2397) R33D3M33R
»

PHP - Register form

Oddelek: Izdelava spletišč
241525 (1153) roli
»

Skrivanje gesel

Oddelek: Izdelava spletišč
392497 (1737) Tr0n

Več podobnih tem