[SimonP]

Det är lite svårt att förklara, egentligen måste man kolla på algoritm-koden för att förstå det helt...

Men t.ex MD5 använder 6 st integers för att spara den interna statusen/contexten inuti algoritmen, varje gång man hashar någonting så är det dessa som ändrar värde, förenklat sagt.

Så om jag hashar saltet "4398jdfshjreg85r9t985dsflkjdsfijl98" kommer att integer:na att se ut ungefär så här efter att md5-algoritmens kärna, md5_update, körts igenom:
state[0] = 0x12452301;
state[1] = 0xbfcddb89;
state[2] = 0x18ba0cfe;
state[3] = 0x78325476;
count1=22
count2=3

Sen lägger jag på lösenordet "mittlösenord", efter att md5_update är klar ändras variablerna då till:

state[0] = 0x18442341;
state[1] = 0xebc4db81;
state[2] = 0x634ba0fb;
state[3] = 0x4ee25498;
count1=11
count2=7

Om inget mer skall hashas kör man den sista funktionen (md5_final) för att för fram den slutgiltiga hashsumman.

Internt så består alla hashfunktioner av 3 funktioner, _init(), _update() och _final()
Så för ovanstående exempel blir det alltså nedanstående för att leta efter lösenordet:

MD5_CONTEXT ctx;

bruteforce loop
{
	ctx = md5_init(NULL);
	md5_update(ctx,"4398jdfshjreg85r9t985dsflkjdsfijl98");
	md5_update(ctx,brutestring);
	summa = md5_final(ctx);
	if (summa == myhash) exit;
}

Om jag nu vill snabba upp en bruteforce-attack sparar jag undan värdena i ctx efter hashningen av saltet:

MD5_CONTEXT ctx;
MD5_CONTEXT backupctx;

ctx = md5_init(NULL);

// Hasha saltet
md5_update(ctx,"4398jdfshjreg85r9t985dsflkjdsfijl98");

// Spara undan den interna statusen
backupctx = ctx;

bruteforce loop
{
	ctx = md5_init(backupctx);
	md5_update(ctx,brutestring);
	summa= md5_final(ctx);
	if (summa == myhash) exit;
}

-----------Ovanstånde är bara Pseudocode-------

Jag slipper nu att köra md5_update två gånger, vilket innebär att jag sparar CPU-tid.

Om man lägger saltet sist är är det går det ej att spara undan den interna statusen på samma sätt eftersom "brutestring" ändras hela tiden.

[jimmie]

Originally posted by SimonP@Jul 28 2008, 15:05
Det är lite svårt att förklara, egentligen måste man kolla på algoritm-koden för att förstå det helt...

Men t.ex MD5 använder 6 st integers för att spara den interna statusen/contexten inuti algoritmen, varje gång man hashar någonting så är det dessa som ändrar värde, förenklat sagt.

Så om jag hashar saltet "4398jdfshjreg85r9t985dsflkjdsfijl98" kommer att integer:na att se ut ungefär så här efter att md5-algoritmens kärna, md5_update, körts igenom:
state[0] = 0x12452301;
state[1] = 0xbfcddb89;
state[2] = 0x18ba0cfe;
state[3] = 0x78325476;
count1=22
count2=3

Sen lägger jag på lösenordet "mittlösenord", efter att md5_update är klar ändras variablerna då till:

state[0] = 0x18442341;
state[1] = 0xebc4db81;
state[2] = 0x634ba0fb;
state[3] = 0x4ee25498;
count1=11
count2=7

Om inget mer skall hashas kör man den sista funktionen (md5_final) för att för fram den slutgiltiga hashsumman.

Internt så består alla hashfunktioner av 3 funktioner, _init(), _update() och _final()
Så för ovanstående exempel blir det alltså nedanstående för att leta efter lösenordet:

MD5_CONTEXT ctx;

bruteforce loop
{
	ctx = md5_init(NULL);
	md5_update(ctx,"4398jdfshjreg85r9t985dsflkjdsfijl98");
	md5_update(ctx,brutestring);
	summa = md5_final(ctx);
	if (summa == myhash) exit;
}

Om jag nu vill snabba upp en bruteforce-attack sparar jag undan värdena i ctx efter hashningen av saltet:

MD5_CONTEXT ctx;
MD5_CONTEXT backupctx;

ctx = md5_init(NULL);

// Hasha saltet
md5_update(ctx,"4398jdfshjreg85r9t985dsflkjdsfijl98");

// Spara undan den interna statusen
backupctx = ctx;

bruteforce loop
{
	ctx = md5_init(backupctx);
	md5_update(ctx,brutestring);
	summa= md5_final(ctx);
	if (summa == myhash) exit;
}

-----------Ovanstånde är bara Pseudocode-------

Jag slipper nu att köra md5_update två gånger, vilket innebär att jag sparar CPU-tid.

Om man lägger saltet sist är är det går det ej att spara undan den interna statusen på samma sätt eftersom "brutestring" ändras hela tiden.

Härligt bra svar!

[MMC]

Otroligt roligt att se kompetens av den här klassen på en forumdel som oftast består av frågor om hur man ändrar saxad PHP-kod till att skriva ut A istället för B. Tack, SimonP!

[emilv]

Originally posted by Drew@Jul 27 2008, 23:44
Det är ju åtminstone vänligt av osCommerce att lägga med saltet i databasen. Känns lite meningslöst att salta då.

Det är inte alls meningslöst. Med ett dynamiskt salt (unikt för varje användare) måste lösenordet knäckas för varje användare. Med ett enda fast salt kan man räkna ut ett lösenord och sedan jämföra mot samtliga användare för se om det träffar någon, eller helt sonika räkna ut regnbågstabeller för det aktuella saltet.
Exempel:

Användare 1 - Lösen: apa
Användare 2 - Lösen: banan

== Fast salt ==
Säg att vi (attackeraren) hashar lösenordet banan tillsammans med det fasta saltet. Då kan vi testa denna hash mot hasharna för båda användarna och se, vi får en träff med en enda uträkning.

== Dynamiskt salt ==
Nu hashar attackeraren ordet banan för varje enskild användare, vilket ökar tidsförbrukningen avsevärt om det är många användare.


Man kan ju dessutom ha både ett fast (i sin applikationskod) och ett dynamiskt (i databasen) salt, för att göra det svårare om man bara får reda på det ena saltet. Man kan om man vill försöka lagra saltet i en egen tabell, eller med applikationskod räkna ut saltet från exempelvis användarnamn och registreringsdatum, men det är inte säkert att det är värt besväret.

[Yepp]

Originally posted by MMC@Jul 28 2008, 16:36
Otroligt roligt att se kompetens av den här klassen på en forumdel som oftast består av frågor om hur man ändrar saxad PHP-kod till att skriva ut A istället för B. Tack, SimonP

Instämmer till fullo! Härligt när man känner att man verkligen kan lära sig mer, och samtidigt får inse hur lite man själv faktiskt kan. Precis den här typen av resurser som efterlängtas. Kjempegreit helt enkelt!

[Jonas]

Originally posted by tartareandesire@Jul 28 2008, 14:02
I http://phpsec.org/articles/2005/password-hashing.html från Php Security Consortium läggs också saltet i början av strängen [antar att Jonas exempel ovan är hämtat därifrån]. Tycker inte heller det borde göra någon skillnad?

Det är samma kod. Tyckte det var ett bra exempel. Synd bara att man nu har verkställt det hela när man får läsa vad SimonP skrivit.

Underbart skrivit SimonP, creds till dig.

[SimonP]

Originally posted by Jonas@Jul 29 2008, 00:08
Det är samma kod. Tyckte det var ett bra exempel. Synd bara att man nu har verkställt det hela när man får läsa vad SimonP skrivit.

Underbart skrivit SimonP, creds till dig.

Tack för era vänliga ord!
Det är som sagt ett mkt komplext ämne, det är ofta man ser sk. "experter" som postar felaktig eller dålig kod på nätet, ur säkerhetsmässig synpunkt.

Jonas, det är dock ingen större katastrof , om någon lyckas dumpa databaser där man lagt saltet först kan attackerarna iofs tjäna ca 20-30% tidsmässigt vid bruteforce-attacker, men det finns ju flera andra fördelar med salt, som inte påverkas av att lägger det först eller sist, t.ex attacker som sker med regnbågstabeller blir oftast värdelösa, eller att två olika användare som använder samma lösenord får olika hashsummor tack vara saltet, etc.

Funktionen rand() bör man generellt sett undvika, inte ens om man sysslar med spel bör man använda rand(), dels fungerar den bättre eller sämre beroende på vilken OS servern kör, sen är den inte threadsafe heller, och på vissa operativsystem kan man förutse vilka nummer som slumpas fram, och då försvinner ofta hela meningen med en PRNG (slumptalsgenerator).

Från Linux manualen:

The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call. This might just be the seed value to be used by the next call, or it might be something more elaborate. In order to get reproducible behaviour in a threaded application, this state must be made explicit. The function rand_r() is supplied with a pointer to an unsigned int, to be used as state. This is a very small amount of state, so this function will be a weak pseudo-random generator

Om man vill ha hyffsat bra slumptal till t.ex lösenordssalt, spel eller annat är det bättre att byta ut rand() mot mt_rand().

Ska man använda slumptal till nycklar för stark kryptering räcker inte ens mt_rand() till. Teorin bakom CSPRNG:s (kryptografisk säkra slumptalsgeneratorer) är mer komplicerad än för vanliga PRNG:s.

Vissa webbaserade tjänster, t.ex pokersidor kör faktiskt med TRNG:s (äkta slumptalsgeneratorer) inpluggade i servern via USB, just för att få så "korrekta" slumpnummer som det är möjligt.

[Marcin]

MD5 ses väl som gränsande till förlegat.

Varför in en SHA512-hash på lösenord med ett långt salt, unikt för varje användare. Må verka som overkill men förhoppningsvis behöver man inte oroa sig ett tag framöver.


Här finns lite performance-tabeller: http://msdn.microsoft.com/en-us/library/ms978415.aspx

[SimonP]

Originally posted by Marcin@Aug 11 2008, 06:56
MD5 ses väl som gränsande till förlegat.

Varför in en SHA512-hash på lösenord med ett långt salt, unikt för varje användare. Må verka som overkill men förhoppningsvis behöver man inte oroa sig ett tag framöver.


Här finns lite performance-tabeller: http://msdn.microsoft.com/en-us/library/ms978415.aspx

Fast som lösenordshash funkar MD5 fortfarande bra, SHA-xxx är bättre främst för att en bruteforce-attack tar lite längre tid.

SHA-512 faktiskt helt overkill, och även onödigt. Dels så drar den betydligt mer CPU och dels så ökar lagringsutrymmet för hasharna med 100%. Jag skulle vilja jämföra det med att nån försöker bygga ett bombsäkert hus där man har 30 cm tjocka betongväggar och har satt in en 40cm tjock ståldörr (SHA-256) , huset blir inte säkrare för att man byter ut dörren mot en 80 cm tjock ståldörr (SHA-512), det är ändå väggarna som är den svaga länken...

Så länge ingen hittar en svaghet i SHA-256 kommer den räcka ända tills man har kvantdatorer som fungerar i praktiken (för kryptografi), och det är långt, långt dit h34r:

[znap]

Tar tillfället i akt och frågar om denna funktion är en bra lösning. Själv känner jag mig hyffsat noob på det här med säker kryptering av lösenord. Med följande funktion följer jag dessa principer som jag snappat upp på lite här och där på nätet.

- Blanda md5 och sha1
- Kryptera flera gånger om
- Använd ett dynamiskt salt kopplat till användarens lösenord
- Använd även ett statiskt salt som man "gömmer" någonstans i applikationskoden

	function generatePassword($password, $salt) {
 $str = md5($password.$salt);
 for($i=0; $i<5; $i++) {
 	$str = sha1($str);
 }	
 return md5($salt.($str).$salt.STATIC_SALT);	
	}

Är något onödigt? Är det något annat jag bör tänka på?

// Vic