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.

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

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

Varför inte något sådant?

//Remove

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

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.

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 :)

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?

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:
Om jag nu vill snabba upp en bruteforce-attack sparar jag undan värdena i ctx efter hashningen av saltet:

-----------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!

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!

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.

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!

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

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 :ph34r:

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

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

// Vic

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.

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.

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:
Om man får en randmax värde som är lågt, typ < 65536, så bör man fixa detta.

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

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.

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.

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.

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.

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.

SSL är det enda rätta oavsett...

Om du kodar på clientside, ja? Vad händer? Jo, du skickar en hash istället för ett lösenord, i vilket fall som helst så är hashen lösenordet istället.
Sniffar man trafiken så behöver man bara skicka hashen istället.

Edit: läste igenom vad du skrev igen och ser att jag misstolkade helt.. :)

Ja som sagt.. SSL är det ända rätta om man vill vara på det torra.

Den ända tryggheten att hasha lösenordet med javascript sha256 är ju att hackaren inte får reda på själva lösenordet som potentiellt kanske används av användaren till andra konton på andra sidor (typ mailkonto etc.). SÅ jag syftade inte på att det var någon ersättare till SSL.

Fast det är mkt bättre för användarna om attackeraren bara får tag på hashen istf. lösenordet, det är ju ofta som attackerarna försöker använda lösenordet på andra webbplatser.

Det bästa är att köra krypteringen på klientsidan och skydda trafiken med SSL.

Att hasha lösenordet på klientsidan och skicka det med en SSL anslutning blir väl kaka på kaka? Eller har jag missat något :)

Ja, SSL skyddar bara trafiken, SSL har inget med webbsidans egna script att göra.

Jo det är jag medveten om, men frågan lyder då, varför hasha ett lösenord som skall skickas under en skyddad anslutning? Bortsett från att förhindra att ägaren av sajten hijackar lösenordet då...

Det , det kan finnas flera anledningar där SSL inte hjälper helt:
1. Ägaren är en bad guy
2. Man sitter på en delad webbserver där en annan webbsida blivit hackad och på så sätt kommer dom åt din webbsida
3. Servern blir stulen/omdirigerad

För ovanstående fall kan man göra en del grejor för att försvåra processen för hackarna:

-Skydda serverkoden, t.ex en med en PHP-encryptor
-Skydda klientkrypteringen med en signering, vilket innebär att om hackaren skickar ut en falsk klientkryptering så får klienten upp en varningsruta i webbläsaren, eller se till att klientkrypteringen måste installeras som en plugin i webbläsaren istf. att den skickas från servern.

Den bästa anledningen till att aldrig lagra lösenord i klartext är väl att hackarna måste vänta till varje användare loggar in för att kunna plocka lösenordet/hashen (dvs. man använder salt+en bra hashrutin i databasen)

Man kan göra all kryptering med Javascript, SHA-512, PGP etc. , nackdelen är att det går långsammare + att det är mkt svårare att göra någon sorts signering av klientkoden, Java/ActiveX är bättre på detta.

Låter vettigt, tack för tipsen.

Btw vart hittar jag SHA-512 för javascript? Har googlat men utan framgång.

Ex: http:// jssha .sourceforge.net/

Men som jag skrev tidigare i denna tråd är SHA-512 overkill.