[tartareandesire]

När det gäller lösenordslagring så har det redan diskuterats en del på WN men jag kunde inte hitta något om lämplig längd att salta sin hashade sträng med? Nu vill jag inte tala om vilka längder jag själv använder eftersom det inte gynnar ändamålet så att säga.

[dimka]

Jag tycker att osCommerce funktion att kryptera lösenord är bäst!

function encrypt_password($plain) {

$password = '';

for ($i=0; $i<10; $i++) {
$password .= tep_rand();
// tep_rand() returnerar ett slumpvis tioställigt numeriskt värde (ex. 3541976724)
// utifrån php-funktionerna nedan;
// mt_srand((double)microtime()*1000000);
// mt_rand();
}

// utifrån det slumpade "lösenordet" ovan hämtas saltet
$salt = substr(md5($password), 0, 2);

$password = md5($salt . $plain) . ':' . $salt;

return $password;

}

[Drew]

Det är ju åtminstone vänligt av osCommerce att lägga med saltet i databasen. Känns lite meningslöst att salta då.

[SimonP]

Originally posted by dimka@Jul 27 2008, 23:30
Jag tycker att osCommerce funktion att kryptera lösenord är bäst!

Det är inte bra att lägga saltet först som dom gör här: md5($salt . $plain) , eftersom en bruteforce attack blir enklare då, saltet skall läggas sist eller på båda sidorna om lösenordet.

Längden på saltet bör ligga på mer än 2 bytes, för att förhindra dom som sitter på regnbågstabeller där man även "inkluderat" salt, men samtidigt är det onödigt ha en större salt än hashalgoritmens egna styrka, i md5:s fall 16 bytes (32 st hex).

[Jonas]

function generateHash($plainText, $salt = null)
{
  if ($salt === null)
    $salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
  else
    $salt = substr($salt, 0, SALT_LENGTH);

  return $salt . sha1($salt . $plainText);
}

Varför inte något sådant?

[gsoc]

Ursprungligen postat av SimonP

Det är inte bra att lägga saltet först som dom gör här: md5(salt . plain) , eftersom en bruteforce attack blir enklare då, saltet skall läggas sist eller på båda sidorna om lösenordet.
Längden på saltet bör ligga på mer än 2 bytes, för att förhindra dom som sitter på regnbågstabeller där man även inkluderat salt, men samtidigt är det onödigt ha en större salt än hashalgoritmens egna styrka, i md5:s fall 16 bytes (32 st hex).

//Remove

[SimonP]

Originally posted by Jonas@Jul 27 2008, 23:58

function generateHash($plainText, $salt = null)
{
 * *if ($salt === null)
 * * * *$salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
 * *else
 * * * *$salt = substr($salt, 0, SALT_LENGTH);

 * *return $salt . sha1($salt . $plainText);
}

Varför inte något sådant?

Denna funktion är inte så bra av två anledningar:

-salt läggs på före lösenordet
-funktionen rand() är dålig, mt_rand() rekommenderas för kryptofunktioner

[Jonathan P]

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å.

Man måste ju veta saltet för att kunna jämföra lösenordet i databasen med det som användaren uppger vid en autentisering. Fördelen med att ha ett dynamiskt salt är att förhindra möjligheten att kunna bruteforcea en hel databas med en regnbågstabell.

[jimmie]

Ursprungligen postat av SimonP

Denna funktion är inte så bra av två anledningar:

-salt läggs på före lösenordet
-funktionen rand() är dålig, mt_rand() rekommenderas för kryptofunktioner

Nu har jag saltet längst bak men har funderat lite på varför man egentligen gör det? På vilket sätt blir bruteforce svårare?

Att bruteforca antingen xxxxxxxxxxf3931e5339f5073b23188d1b357715a0 eller f3931e5339f5073b23188d1b357715a0xxxxxxxxxx bör väl kräva samma antal försök?

Obs. är måndag idag så hjärnan är inte riktigt igång än

[tartareandesire]

I den här artikeln 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?