![]() |
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!
Citat:
|
Det är ju åtminstone vänligt av osCommerce att lägga med saltet i databasen. Känns lite meningslöst att salta då.
|
Citat:
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). |
Kod:
function generateHash($plainText, $salt = null) |
Citat:
|
Citat:
-salt läggs på före lösenordet -funktionen rand() är dålig, mt_rand() rekommenderas för kryptofunktioner |
Citat:
|
Citat:
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: Kod:
MD5_CONTEXT ctx; Kod:
MD5_CONTEXT ctx; 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. |
Citat:
|
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!
|
Citat:
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. |
Citat:
|
Citat:
Underbart skrivit SimonP, creds till dig. |
Citat:
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: Citat:
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 |
Citat:
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 Kod:
function generatePassword($password, $salt) { // Vic |
Citat:
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.
|
Citat:
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: Kod:
<?php |
Citat:
|
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.
|
Citat:
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. |
Citat:
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. |
Citat:
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.
|
Citat:
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. |
Citat:
Det bästa är att köra krypteringen på klientsidan och skydda trafiken med SSL. |
Citat:
|
Citat:
|
Citat:
|
Citat:
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. |
Citat:
|
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. |
Alla tider är GMT +2. Klockan är nu 13:43. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson