[SimonP]

Originally posted by znap@Aug 11 2008, 22:28
- 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

Bara man inte använder inte ett salt som utvinns från användarens lösenord, saltet ska helst genereras slumpmässigt.
Att sedan lägga på ett statiskt salt är bra.

Så din funktion ser bra ut, förutsatt att det dynamiska saltet är ok.

[znap]

Ok, tack för ditt svar! Saltet utvinns inte från användarens lösenord, utan varje användare får ett hyffsat unikt salt.

[SimonP]

Originally posted by SimonP@Aug 1 2008, 13:12
Funktionen rand() bör man generellt sett undvika...

Tänkte bara visa ett IRL exempel på en ny exploit som utnyttjar den dåliga rand() funktionen i PHP, som jag tidigare skrev om.

http://milw0rm.com/exploits/6392

Den kan vara många svenska SMF-forum som är öppna för denna attack:
http://www.google.com/search?hl=sv&lr=lang...2&start=70&sa=N

För att kontrollera om man påverkas av denna exploit:

<?php
echo getrandmax();
?>

Om man får en randmax värde som är lågt, typ < 65536, så bör man fixa detta.

[Jonas]

Originally posted by znap@Aug 11 2008, 22:28

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

Får man fråga varför du skriver över $str 5ggr ?

[Dimme]

Vad än du gör KAN brutoforcas om hackaren känner till din krypteringsalgoritm. Därför säg till att inte sprida här eller någon annanstans koden till din egen algoritm, sen kan du skriva den hur du vill.

[eg0master]

Originally posted by Dimme@Sep 26 2008, 19:09
Vad än du gör KAN brutoforcas om hackaren känner till din krypteringsalgoritm. Därför säg till att inte sprida här eller någon annanstans koden till din egen algoritm, sen kan du skriva den hur du vill.

Det där är ett felaktigt uttalande som dessutom uppmanar till dåliga lösningar ur säkerhetssynvinkel.
Jag kanske märker ord, men allt kan bruteforcas oavsett algoritm givet att man har tillräckligt med tid. Kännedom om algoritmen (om den är dålig) gör dock att man kan ta genvägar i attacken så att man inte behöver göra en brute force utan kan koncentrera sig på en mindre mängd möjliga nycklar/lösenord.

En av de första saker man får lära sig om kryptering och olika algoritmers säkerhet är att man skall alltid utgå ifrån att motståndaren känner till algoritmen, men inte nyckeln när man bedömer styrkan hos ett krypto. En krypteringsalgoritm som bygger på att en del av algoritmen är hemlig är värdelös eftersom algoritmen inte går att byta ut. Det är bara en tidsfråga innan algoritmen kommer i fiendens händer. Därför är det att uppmana till dåliga lösningar att påstå att man skall hålla sin algoritm hemlig för det invaggar dig i en falsk säkerhet om din algoritms styrka.

Däremot måste vi anta (när vi värderar styrkan av algoritmen) att nyckeln (i det här fallet saltet) är okänd. Och då är ju ett unikt salt per användare, som är lagrat i databasen sannolikt den bästa lösningen.Och vi måste utgå ifrån att den somanvänder en sådan algoritm vet hur han skyddar sin databas så att inte salten hamnar i felaktiga händer. Men det handlar om säker lagring av nycklar och har inget med algoritmen att göra.

[emilv]

Originally posted by eg0master@Sep 27 2008, 11:12
Däremot måste vi anta (när vi värderar styrkan av algoritmen) att nyckeln (i det här fallet saltet) är okänd. Och då är ju ett unikt salt per användare, som är lagrat i databasen sannolikt den bästa lösningen.

Om vi skapar en algoritm som är helt bombsäker så länge nyckeln är hemlig men värdelös om man känner till nyckeln, då? Vad är då meningen med att kryptera lösenorden från första början, när både lösenorden och kryptonyckeln lagras sida vid sida?

Jag föredrar en hash med dubbla salt, ett som lagras i applikationskoden och ett dynamiskt som lagras med användaren i databasen. På så sätt måste man få reda på båda för att knäcka lösenordet. Det finns åtskilliga exempel på när knäckare fått tag på databasen med hjälp av en SQL-injektion, men inte fått tag på applikationskoden. En lösning som kräver både applikationskod och databas för att knäcka (utan råkraftsattack) är därför säkrare än en som bara kräver databasen.

[eg0master]

Att spara ett krypterat lösenord tillsammans med nyckeln är som at ha det i klartext - ja. Men nu pratar vi ju om envägskryptering (dvs en hash). Vi vet idag at md5 inte är så säkert eftersom det går att återskapa en hash utan att känna till lösenordet. Krypterar du istället lösenordet med SHA-512 så är du iaf vad vi vet idag säker.

En annan viktig anledning till att kryptera lösenordet är att bara användaren skall känna till lösenordet. Det bästa är ju alltid om lösenordet krypteras på klienten hos användaren så att den som "äger sidan" aldrig ser användarens lösenord. Det ärju bara at acceptera att de flesta använder samma lösenord på många olika sajter och om krypteringen sker redan på klienten så får individen ett litet extra skydd.

Bara för att du har ett salt som ligger i applikationskoden betyder det inte att du har en hemlig algoritm. Det finns inget likhetstecken mellan algoritm och applikationskod (lika lite som det som ligger i databasen alltid ärnyckeln). Det du beskriver är en tvådelad nyckel där de två delarna är lagrade på två olika ställen. Självklart är det säkrare att använda en metod där nyckeln är tudelad på detta sätt eftersom gemene man verkar ha så svårt att säkra upp sina databaser.

Så eftersom sha512 väl saknas i php och folk misslyckas med att säkra sina databaser om och om igen så är väl den bästa lösningen att använda sha1 och inte md5. sha1 är bätre än md5. Ha gärna ett javascript som hashar lösenordet en gång med SALT1 på klienten innan det skickas (ger användaren en extra trygghet att sajtägaren inte kan sniffa lösenordet). Hasha en gång till med SALT2 som finns i databasen (ett per användare). Hasha ytterligare en gång med ett salt som finns i applikationskoden. Det är väl det bästa man kan göra under omständigheterna.

Avslutningsvis en liten jämförelse mellan två olika algoritmer och nycklar:
Algoritm 1: Skapa en ny sträng med två tecken, följt av lösenordet, följt av två tecken. Kör SHA1 på det.
Algoritm 2: Skapa en ny sträng av användarnamnet och lösenordet. Kör SHA1 flera gånger på det.

Om vi gissar att attackeraren har tillgång till allt utom nyckeln, dvs till och med har en hash som är skapad utifrån ett känt lösenord så är styrkan följande:
Algoritm 1 har då en "nyckel" på fyra tecken. Om vi dessutom vet att det är stora bokstäver (A-Z) har vi totalt 456976 olika kombinationer som måste prövas.
Algoritm 2 har bara "antalet gånger SHA1 körs" som nyckel. och det är ju troligen ett ganska litet tal.

Avslutningsvis 2:
En sista sak att komma ihåg är att inget krypto är säkert. Det enda styrkan på ett krypto säger är hur lång tid det tar att knäcka det givet en viss mängd resurser. men grundtesen är alltid: Algoritmen känd - nyckeln okänd.

[stakes]

Originally posted by eg0master@Sep 28 2008, 11:45
Så eftersom sha512 väl saknas i php och folk misslyckas med att säkra sina databaser om och om igen så är väl den bästa lösningen att använda sha1 och inte md5. sha1 är bätre än md5. Ha gärna ett javascript som hashar lösenordet en gång med SALT1 på klienten innan det skickas (ger användaren en extra trygghet att sajtägaren inte kan sniffa lösenordet). Hasha en gång till med SALT2 som finns i databasen (ett per användare). Hasha ytterligare en gång med ett salt som finns i applikationskoden. Det är väl det bästa man kan göra under omständigheterna.

Det finns sha256 i php i funktionen mhash() (som jag brukar använda mig av) sen finns det även ett PECL extension som ger dig tillgång till SHA384 samt SHA512 (bör för övrigt vara installerad by default om du har PHP 5.1.2 eller nyare)

http://se.php.net/manual/en/function.hash-algos.php

EDIT as of PHP 5.3.0 så används inte mhash() längre utan bara hash() som då även ger dig tillgång till sha512.

[stakes]

Problemet ligger dock kvar i att det inte finns något sätt att sha512 lösenord i javascript (rätta mig om jag har fel), vilket gör att det skickas i klartext innan det når servern, om du inte har en SSL anslutning dvs. Av den anledningen ligger jag kvar med sha256 i mina applikationer.