Reticent Skrevet 15. november 2006 Del Skrevet 15. november 2006 (endret) Driver for tiden og setter opp et forum og begynte derfor å lure på hvordan beskyttelse av passord fungerer. Har forstått såpass at når man oppgir et passord i registreringen lages det en "hash" av passordet som lagres i databasen. På den måten lagres ikke passordet i det hele tatt. Men da lurer jeg på. Hvordan fungerer prosessen hvor man sjekker om man har skrevet riktig passord? Man kan, så vidt jeg har forstått, ikke føre prosessen tilbake, d.v.s. finne tilbake til passordet fra hashen. Endret 22. november 2006 av Mizt Lenke til kommentar
missiongul Skrevet 15. november 2006 Del Skrevet 15. november 2006 (endret) Hvis passordet eks. blir lagret med md5() i registreringen. Når man logger inn da, blir passordet man logger inn med også hashet. Det hashede passordet man bruker til å logge inn med blir sjekket mot det hashede passordet som ligger i databasen. Da trenger den ikke å dekryptere det krypterte passordet som ligger i databasen. Edit: Ble litt rot ja. Håper du forstår det... Endret 15. november 2006 av missiongul Lenke til kommentar
Reticent Skrevet 15. november 2006 Forfatter Del Skrevet 15. november 2006 Absolutt forståelig. Men når jeg forsøker å hashe et passord i php og echoe det ut forandrer hashen seg for hver gang jeg oppdaterer. Betyr det at når man sammenligner to hasher trenger ikke de to være like for å finne ut om de to passordene de stammer fra er like? Lenke til kommentar
Peter Skrevet 15. november 2006 Del Skrevet 15. november 2006 Absolutt forståelig. Men når jeg forsøker å hashe et passord i php og echoe det ut forandrer hashen seg for hver gang jeg oppdaterer. Betyr det at når man sammenligner to hasher trenger ikke de to være like for å finne ut om de to passordene de stammer fra er like? 7291805[/snapback] Nei, det stemmer ikke. hashen til en streng vil alltid være den samme, det er hele poenget. md5('abc') vil alltid være lik md5('abc') Lenke til kommentar
Reticent Skrevet 15. november 2006 Forfatter Del Skrevet 15. november 2006 Ja, beklager, brukte feil funksjon i php. Men betyr det at det går an å dehashe et passord, eller kan man stole på at passordet er trygt når det er lagret en hash i databasen? Lenke til kommentar
Peter Skrevet 15. november 2006 Del Skrevet 15. november 2006 Du kan ikke "dehashe" en hash, det er litt av poenget. Det er en såkalt enveisalgoritme. Passordet er tryggere, og du kan jo anta at det er MYE tryggere enn ren tekst, men allikevel så finnes det ting som f.eks. rainbowtables (google it) dersom noen skulle få tak i de hashede passordene. Et triks kan være å hashe to ganger. f.eks. sha1(md5('abc')) eller md5(md5('abc')) eller sha1(sha1('abc')) Lenke til kommentar
Blib Skrevet 15. november 2006 Del Skrevet 15. november 2006 Du må huske på at det finnes enorme databaser på internett hvor man kan slå opp en md5-hash og med god sannsynlighet finne ut hva passordet er. Mye raskere enn bruteforcing. Det du kan gjøre da er å salte passordet. Salting er å forsterke passordet før det hashes. Istedenfor å lagre md5($pass) i databasen lagrer du heller: md5("432hrnfgerlgjn493tnfgd8" + $pass) Så kjører du samme salt på innloggingspassordene du får. Du kan også legge til et salt etter passordstringen og dobbelthashe for ekstra sikkerhet. Lenke til kommentar
endrebjo Skrevet 15. november 2006 Del Skrevet 15. november 2006 Og med et unikt (random) salt for hvert passord blir det enda bedre. Saltet må da lagres f.eks i en egen kolonne i databasen. Og sha1 er vel sikrere enn md5. Lenke til kommentar
Martin A. Skrevet 15. november 2006 Del Skrevet 15. november 2006 (endret) Og for å lage et random hash, bruker jeg denne "lille" kodesnutten skrevet av en eller annen på forumet /* SALTER Designed for "salting hashes". Returns a 32 character long random string including a-z,A-Z,0-9 and some special characters. Function can be used to generate random passwords. */ function make_salt() { // a secure password needs a-z,A-Z,0-9 and some special characters // (actually, it doesn't really matter since the hash will be very // different no matter... But, it makes it harder to bruteforce.) $az = array("a","b","c","d","e","f","g","h","i","j","k","l","m", "n","o","p","q","r","s","t","u","v","w","x","y","z"); $AZ = array("A","B","C","D","E","F","G","H","I","J","K","L","M", "N","O","P","Q","R","S","T","U","V","W","X","Y","Z"); $chars = array(".",",","/","&",":",";","-","_","*","(",")","[","]", "{","}","+","?","%","#","!","<",">","~","$",'"',"'", "@",";","="); // lets have 8 random numbers for($i=0; $i<8; $i++) { $str[] = rand(0,9); }; // lets have 8 random a-z for($i=0; $i<8; $i++) { $str[] = $az[rand(0,count($az)-1)]; }; // lets have 8 random A-Z for($i=0; $i<8; $i++) { $str[] = $AZ[rand(0,count($AZ)-1)]; }; // lets have 8 random special characters for($i=0; $i<8; $i++) { $str[] = $chars[rand(0,count($chars)-1)]; }; // lets shuffle it //$str = preg_split('//',$str,-1,PREG_SPLIT_DELIM_CAPTURE); shuffle($str); $str = implode("",$str); return $str; }; Og måten jeg da bruker det på er: PHP <?php$salt = make_salt(); /*Brukes for å knytte make_salt() til en variabel, slik at verdien make_salt() gir ikke endres for hver gang den skal brukes i scriptet */ $passord = mysql_real_escape_string($_POST['passord']); $q = "INSERT INTO users(username, pass, salt) VALUES('ost', '$passord', '$salt')"; /*osv osv osv, selvfølgelig med litt sjekking av riktig lengde på ditt og datt, og falige/ulovlige tegn her og der*/ Og som man sjekker at dette stemmer, slik: <?php $brukernavn = mysql_real_escape_string($_POST['brukernavn']); $passord = mysql_real_escape_string($_POST['passord']); $submit = $_POST['submit']; $spørring = "SELECT * FROM brukere WHERE brukernavn = '$brukernavn'"; $sql = mysql_query($spørring); if(isset($submit)) { if( !empty($brukernavn) && !empty($passord)) { $rad = mysql_fetch_array($sql); if(mysql_num_rows($sql) > 0) { if($rad['passord'] == sha1($rad['salt'].$passord)) { $_SESSION['dittogdatt'] = "en verdi"; echo 'Du er nå logget inn'; } else { echo 'Feil passord'; session_destroy(); } } else { echo 'Brukernavnet eksisterer ikke i databasen'; } } else { echo 'Begge feltene må fylles ut'; } } ?> Endret 15. november 2006 av M4rTiN Lenke til kommentar
endrebjo Skrevet 15. november 2006 Del Skrevet 15. november 2006 32 byte salt er kanskje litt overkill? Lenke til kommentar
Zethyr Skrevet 15. november 2006 Del Skrevet 15. november 2006 Et 12-byte salt vil vel gjøre mer enn god nok nytte. De fleste regnbue-tabeller vil da ikke kunne brukes, og å knekke passordet ved ren datakraft vil ta lang tid. Lenke til kommentar
Matsemann Skrevet 17. november 2006 Del Skrevet 17. november 2006 Men det som er like viktig er å validere input, ellers behøver man ikke passord Lenke til kommentar
ilpostino Skrevet 21. november 2006 Del Skrevet 21. november 2006 dette var interesang lesing. henger meg på denne tråden. Lenke til kommentar
Kagee Skrevet 21. november 2006 Del Skrevet 21. november 2006 Crypt er vel absolutt enklest: From the manualen (http://no2.php.net/crypt): crypt() will return an encrypted string using the standard Unix DES-based encryption algorithm or alternative algorithms that may be available on the system. Arguments are a string to be encrypted and an optional salt string to base the encryption on. See the Unix man page for your crypt function for more information. If the salt argument is not provided, one will be randomly generated by PHP each time you call this function. I manualen er det også tips om hvordan den brukes. Lenke til kommentar
Matsemann Skrevet 21. november 2006 Del Skrevet 21. november 2006 Det er bare det at om folk først får tilgang til databasen og passordene, er ikke det at de kan finne passordet det verste. Om du hasher det hundre ganger (noe som er unødvendig ), og de finner det, så finner de det nok ikke i en regnbue-tabell. Men må det være så vanskelig? Man kan da bare hashe 123, bytte ut hashen i databasen med sin hash. Det bør ikke være noe problem om en først klarer å få tilgang til hashene. Og om en har tilgang til databasen slik uten videre, kan man jo og bare slette alt der. Så validering av input, slik at folk ikke kan trenge inn egen kode, er nok mye viktigere enn kryptering av passord. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå