ripemd320 hash - bra sikkerhet ?

[Thomas.]

<?php

echo  hash ( ripemd320, 'hei' );

?>

 

Dette resulterer i:

3cb0a4da168a2f534a97625f0376abcc2567dc38f9985e2932bb92ece0c0dc965789241404ff0c28

 

Er dette bra sikkerhet?

Kan det dekrypteres på noen måte?

Endret 22. januar 2010 av Thomas.

[Cemi]

Alt kan vel i teorien dekrypteres, men ripemd320 er såvidt jeg vet en veldig sikker kryptering.

[ze5400]

Errh, nå er det vel strengt tatt hashing og ikke kryptering dette dreier seg om.

 

At noen ter seg tiden til å bruteforce den er heller tvilsomt, så ja, det er mer enn sikkert nok.

[xqus]

Som ze5400 sier er dette et enveis hash, og ikke toveis kryptering.

Et slikt hash er mulig å "dekryptere" ved hjelp av brute force, feks. ved oppslag i rainbow tables.

 

Dersom du bruker dette for å lagre passord i en database (som er den vanligste bruken av hash) er dette såklart bedre enn å lagre det i klartekst, men heller ikke helt optimalt.

Det du da bør gjøre er å generere et 'salt', som du benytter når du hasher passordet. Dette lagres sammen med passord hashet i databasen.

Feks:

<?php

// Generer salt, dette må ikke gjøres om til et md5 hash, men det kan være praktisk
$salt = md5(mt_rand().microtime());

$pwHash = hash(ripemd320, $salt.'hei');

 

Når du så skal kontrollere om en bruker skrev inn korrekt passord bruker du da saltet sammen med input fra bruker og ser om det resulterer i samme hash.

 

Dette gjør brute forcing vanskelig, og rainbow tables ubrukelig.

[ze5400]

En liten kommentar til det;

 

Bruteforcing av passordet til en enkeltbruker blir ikke vanskeligere (da saltet også ville være kjent for 'the bad guys', om de først har fått tak i hashen), men man kan ikke kjøre en bruteforce mot en hel brukerliste på en gang.

[xqus]

Det er korrekt. Eneste grunnen til at det blir vanskeligere er at forhåndsgenererte lister med hash og passord vil ikke kunne brukes.

Endret 23. januar 2010 av xqus

[Thomas.]

Som ze5400 sier er dette et enveis hash, og ikke toveis kryptering.

Et slikt hash er mulig å "dekryptere" ved hjelp av brute force, feks. ved oppslag i rainbow tables.

 

Dersom du bruker dette for å lagre passord i en database (som er den vanligste bruken av hash) er dette såklart bedre enn å lagre det i klartekst, men heller ikke helt optimalt.

Det du da bør gjøre er å generere et 'salt', som du benytter når du hasher passordet. Dette lagres sammen med passord hashet i databasen.

Feks:

<?php

// Generer salt, dette må ikke gjøres om til et md5 hash, men det kan være praktisk
$salt = md5(mt_rand().microtime());

$pwHash = hash(ripemd320, $salt.'hei');

 

Når du så skal kontrollere om en bruker skrev inn korrekt passord bruker du da saltet sammen med input fra bruker og ser om det resulterer i samme hash.

 

Dette gjør brute forcing vanskelig, og rainbow tables ubrukelig.

 

Dette fungerer da ikke bruke i et logginn system?

Blir jo forskjellig hele tiden.

[ze5400]

Jo, det fungerer. Du lagrer jo saltet...

Endret 23. januar 2010 av ze5400

[Thomas.]

Jo, det fungerer. Du lagrer jo saltet...

 

Ja, lagre det i databasen er jo ikke noe problem.

Men å sjekke om passordet man skriver inn er likt med det som er i databasen. Det fungerer jo ikke når det er forskjellig hash vær gang?

[ze5400]

Det er jo ikke forskjellig hash hver gang. Du bruker samme salten til samme brukeren hele tiden.

[xqus]

Det blir ikke forskjellig.

 

Når en bruker opprettes genereres et salt. Dette saltet lagres i databasen og brukes hver gang brukeren logger inn. Det genereres ikke nytt salt når du sjekker passordet, men du bruker det samme som når ble brukt når du lagret passord hashet første gang.

[xibriz]

Man kan jo bytte ut saltet for hver gang en person logger inn suksessfult, men da må man jo oppdatere hashen

[Jonas]

Hva slags ekstra sikkerhet mener du det skal gi? Med en gang jeg bruteforcer og klarer å hente ut passordet til en bruker, så har det ikke noe å si hvor mange ganger du genererer nye salter, logger meg bare på med passordet jeg fant tidligere, jeg.

[xibriz]

Hva slags ekstra sikkerhet mener du det skal gi? Med en gang jeg bruteforcer og klarer å hente ut passordet til en bruker, så har det ikke noe å si hvor mange ganger du genererer nye salter, logger meg bare på med passordet jeg fant tidligere, jeg.

 

 

Hehe, logikkutfordring?

 

Tror det er på tide med en liten middagslur

Endret 28. januar 2010 av xibriz

[Even_A]

Slik jeg har løst min passord hash er slik:

En salt er static i scriptet. Denne er det ingen som kan se, men bad guysa KAN finne den ved å se sammenhenger i bruteforce'n. Derfor har jeg 2 salter for å være sikker. En salt som er static og en egen salt som genereres til hver bruker. Grunnen til at jeg har en static salt er fordi den slipper jeg å lagre i databasen, så om de får tak i databasen min har de: den genererte hashen og hele passordhashen.

Om de får tak i skriptet mitt har de kun den statiske. Ergo de må hacke både FTP'n og MySQL'n for å få ut all informasjonen.

 

Mot bruteforce må man lage en login limit. En IP må kun få prøve å logge inn x antall ganger iløpet av x2 antall minutter.

 

Videre er det VIKTIG å sikre SQL query'ne sine. Slik at ingen kan bruke SQL injections mot DB'n din. Lag en validering av formene + bruk mysql_real_escape_string(); om du koder i php.

 

Selv bruker jeg sha256 hash. SHA1 er ikke "sikkert" lenger. Det finnes teoretiske måter å knekke de på. Eneste som mangler er datakraft. Ergo de er et lett bytte om noen år.

Endret 29. januar 2010 av Even_A