[mypay]

självklart ska saker och ting krypteras..

men jag fattade ursprungsfrågan som att det skulle krypteras för att sidägaren inte skulle kunna se lösenordet - och då hjälper ju inte kryptering eftersom han/hon har tillgång till nycklarna

[Jester]

Originally posted by mypay@Jan 21 2005, 02:03
Även om lösenordet lagras krypterat så har ju utvecklaren möjlighet att kika på lösenorden om han/hon vill..

Det hela handlar snarare om hur säkert dom ligger lagrade så att ingen utanför sajten kan få tag i uppgifterna. Det seriösa hos en websajtsägare borde ligga i att inte kika överhuvudtaget

Om man t.ex. MD5-krypterar ett lösenord direkt när det läggs in i databasen ser jag inte riktigt hur databasadministratören skulle kunna "kika" på det. Att byta ut det mot ett för administratören kändt lösenord är väl däremot högst möjligt.

[Schneaker]

Vi har alltid kört med MD5-hashar, och det funkar alldeles utmärkt. Skulle en användare glömma sitt lösenord så kan denne skapa ett nytt lösenord med hjälp av e-postverifiering.

Vi fick intrång i servern av fulhack en gång i somras, vips flöt 30 000 registrerade och aktiverade konton runt på nätet, med uppgifter om lunarnamn, e-postadresser och mycket mer. Hade vi inte haft hashade lösenord så hade "hackarna" lätt kunnat skriva en robot som testade lösenorden mot användarnas lunarkonton. Detta skulle kunna ha resulterat i tusentals borttagna lunarkonton och e-postkonton.
En MD5-hash av ett "vanligt" lösenord är inte svårt att knäcka, vill någon ta reda på ett lösenord och har hashen så är det kört, men man stoppar iallafall robot-missbruk av lösenorden.
Därför anser jag att den som inte hashar sina lösenord allvarligt bör överväga detta.

Vad gäller att ta reda på en användares lösenord så är detta inte något problem. Vi kan ju lägga en if-sats i inloggningen som dumpar intressanta användares lösenord till en textfil, eftersom webservern får dessa i klartext.

[eg0master]

Som någon skrev är en god anledning att hasha lösenorden just den att många användare använder samma namn på flera olika sajter. Och får man ett intrång så är ett hashat lösenord inget värt.

För jag håller inte med om att "En MD5-hash av ett "vanligt" lösenord är inte svårt att knäcka, vill någon ta reda på ett lösenord och har hashen så är det kört".

Efetrsom MD5 är en envägsfunktion så har du ingen nytta av MD5 hashen när du ska lista ut lösenordet. Du kan inte göra någon form av analys av hashen som hjälper dig att hitta lösenordet. Det enda du kan göra är att pröva alla möjliga lösenord. Att du har hashen betyder bara att du vet när du ska sluta (precis som om du har en robot som försöker logga in genom att prova olika lösenord).

VIll påminna om at 128 bitar ger fler möjligheter än antalet atomer i universum. Nu kan ju ingen med säkerhet säga att de vet antalet atomer i universum, men det är i alla fall den liknalse man brukar göra för att beskriva storleken av ett 128-bitars tal...

[anders.n]

Originally posted by eg0master@Jan 21 2005, 22:13
Efetrsom MD5 är en envägsfunktion så har du ingen nytta av MD5 hashen när du ska lista ut lösenordet. Du kan inte göra någon form av analys av hashen som hjälper dig att hitta lösenordet. Det enda du kan göra är att pröva alla möjliga lösenord. Att du har hashen betyder bara att du vet när du ska sluta (precis som om du har en robot som försöker logga in genom att prova olika lösenord).

Dock så är det viktigt att man använder någon form av "salt" också, då det finns färdiga rainbow tables (för-uträknade hashsummor) för olika hash-algoritmer. Har man även med ett bra "salt" när man lagrar hashet så måste man brute-forcea lösenorden.

Sedan är det ju alltid bra att tvinga användarna att ha relativt säkra lösenord också.

[Robert]

Originally posted by eg0master@Jan 21 2005, 17:20
Att säga att "MD5 är bra för det är standard" är rätt, men att i samma mening säga att det är ett problem för det finns olika implementationer av MD5 är inte helt korrekt. Det finns en korrekt implementation och det finns massor av felaktiga implementationer som amatörer gjort själva istället för att använda ett riktigt bibliotek. Vitsen med en standard är ju att det inte finns några tvetydigheter...

Samma mening? Hmm, jag tror inte jag sa det där första?

Men iaf, jag pratar av egen erfarenhet efter att en kund hade köpt ett krypteringsobjekt av en amerikansk mjukvaruutvecklare som tyvär hade felaktigheter (detta upptäcktes efter 2 år av mig). Så ja, visst är det jättebra med standarder, men att kräva en kodrevision när man köper mjukvara av seriösa företag är det väl ingen som tänker på i första taget. Det jag menade var: testa vilka checksummor ni får och dubbeltesta med andra md5 verktyg. Får ni samma resultat = kör på. Även när man kör en "inbyggd" funktionalitet så är det inte bara att tuta och köra (tänker exempelvis på .Net's security classer).


Om ni vill testa lite bruteforce, testa att hasha ett ord här:

www.securitystats.com/tools/hashcalc.php

...klipp ut hashkoden för en av algorithmerna och kör in den här:

www.securitystats.com/tools/hashcrack.php

..och se hur fort den brute-forcear den.

[guran]

Det blev en intressant diskussion om detta. Så länge ett frö är känt för administratören eller programmeraren så går det att knäcka koden. Detta behöver dock inte vara det intressanta.

Låt säga att ett flertal personer på t.ex. en medlemssajt har tillgång till tabellen över medlemmar. I detta fall kan det vara intressant att dölja lösenordet.

En sak som har irriterat mig, är medlemssajter som skickar ut ett brev av typ "Du har inte loggat in på X antal dagar". Du kan logga in på sidan XXX med följande användarnamn och lösenord. Lösenordet är angivet i klartext.

[eg0master]

Originally posted by anders.n@Jan 22 2005, 00:50
Dock så är det viktigt att man använder någon form av "salt" också, då det finns färdiga rainbow tables (för-uträknade hashsummor) för olika hash-algoritmer. Har man även med ett bra "salt" när man lagrar hashet så måste man brute-forcea lösenorden.

Sedan är det ju alltid bra att tvinga användarna att ha relativt säkra lösenord också.

Nja, jag håller inte riktigt med...

Det enda saltet gör är ju att istället för att hasha "mitthemligalösenord" så hashar jag något i stil med "mitthemligalösenordSALT". Så givet en hash och ett känt salt är det brute force som gäller. Och användandet av rainbow tables (tack för att jag får lära mig ett nytt ord idag) funkar väl bara givet att användaren har ett lösenord som är dåligt? En sådan tabell kan ju vara långt ifrån komplett då den rimligen bara innehåller "vanliga" lösenord med olika varianter på case. Den innehåller ju knappast 2^128 värden. Och eftersom tabellen bara innehåller lösenord som ändå är förutsägbara så behöver jag ju inte ens hashen för att knäcka dessa lösenord. Att ett salt är det som krävs för att brute force skall krävas bygger på antagandet att användarna använder lösenord som sin partners namn osv. Och eftersom dessa lösenord knäcks snabbt även utan tillgång till hasharna så känns inte det resonemanget så intressant.
Dessutom skall man alltid förutsätta att algoritmen är känd när man analyserar kryptering och eftersom vi bör förutsätta att algoritmen är känd så är även saltet känt.

Robert, jag kan bara lida med dig och din kund som råkat på en felaktig implementation av MD5. Och det är sorgligt att man inte kan lita på att företag skall leverera en korrekt implementation. Även om man själv inte vill/kan göra en code review så bör man kanske kräva företaget på resultatet av en säkerhets review av deras kod om man köper en krypteringsprodukt. Eller varför inte köra med något gratisverktyg för att verifiera. finns gott om gratis bibliotek för de mest vanliga kryptorutinerna. openssl har väl det mesta vi pratat om här... både php och asp.net har md5 funktioner osv.

[Jonas]

En nackdel med MD5 är att 2st (eller fler) olika filer/strängar/osv kan ge samma hash, det vill säga att man kan komma förbi inloggningen utan att känna till det rätta lösenordet.

[eg0master]

Originally posted by Jonas@Jan 23 2005, 23:28
En nackdel med MD5 är att 2st (eller fler) olika filer/strängar/osv kan ge samma hash, det vill säga att man kan komma förbi inloggningen utan att känna till det rätta lösenordet.

I teorin ja, men i praktiken? Knappast. Som jag skrev tidigare är ett 128 bitars tal (dvs resultatet av MD5 hashningen) så stort att om du begränsar antalet tecken i lösenordet så kommer ingen av de möjliga kombinationerna att ge dubletter av hashkoder.
Mig veterligen så finns det ingen som ens då både data och hash är känd kunnat skapa en dataserie som är annorlunda, men med samma hash.

Att två strängar skulle ge samma hash är inte relevant i sammanhanget för om jag har en "hashtvilling" så kan jag ju lika gärna köra med det "rätta" lösenordet istället för tvillingen...

Hashning av lösenord är fortfarande det säkraste sättet att lagra lösenorden eftersom all typ av vanlig kryptering inte ger någon ökad säkerhet eftersom nycklarna måste finnas på servern och om man kommer åt de krypterade lösenorden i databasen är risken stor att även nycklarna är tillgängliga (för de behövs ju på servern när man skall verifiera lösenord).