En del medlemsidor lagrar användarnas lösenord i klartext. Själv krypterar jag dem alltid och jag kan inte känna till dem. Glömmer användaren bort sitt lösenord så skickas ett nytt lösenord och det är endast mottagaren som känner till det nya.

Enligt min uppfattning tycker jag att en användare ska ha rätt att inte exponera sitt lösenord. En anledning kan vara att användaren använder det för flera sajter och medlemskap. Ja, han eller hon kan använda både användarnamn och lösenord på flera sajter.

Med andra ord, tycker jag det är lite oseriöst att lagra användares lösenord i klartext.

Jag undrar nu vilken uppfattning ni andra har?

Ä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

de få gånger jag har lagrat inloggningslösenord, så har jag krypterat dem och gjort dem omöjliga för någon att läsa.
Vad tjänar jag på att inte kryptera dem?

Filip - då du krypterat dom så kan du ju även dekryptera dom igen.. dvs hur man än gör så är dom inte säkra från utvecklaren

Man kan använda hash och lagra detta i databasen. Hash är en kontrollsumma av en sträng. När användaren väljer sitt lösenord krypterar man det med hjälp av hash och sen lagras hashvärde i databasen. När en användaren sen loggar in med sitt lösen så omvandlas detta med hash först och sen jämförs detta med det hashvärde som finns i databasen.

En hash kryptering kan inte vändas. Det går alltså inte räknat ut lösenordet med hjälp av hashvärdet. Man kan använda hash i bland annat php, asp och asp.net.

/Janne

Sedan bör man använda ett 'salt' också för att man inte lika lätt skall kunna använda för-uträknade hashvärden eller kunna se vilka som har samma lösenord om man kommer över databasen, men.. sparar man inte lösenorden i klartext så bör man vara medveten om det redan.. :)

Appropå det... man kan även implementera bättre skydd på klientsidan.. Jag skulle fixa ett CMS utan tillgång till HTTPS.. När användaren loggar in (och har javascript aktiverat) så hash:ar den lösenordet lokalt innan det skickas (två gånger blah blah hash:at i databasen blah blah). Det blir således mycket säkrare om någon sniffar nätverkstrafiken. Så borde fler siter göra när de inte använder sig av https.

Jag har använt föjande metod i PHP:

<?php
$password = "webmasternetwork";

$encrypted = crypt($password);

if (crypt( $password, $encrypted ) == $encrypted )
echo "Lösenorden matchar!";
else
echo "Lösenorden matchar ej!";
?>

Som Jan Eriksson säger, så kan jag lagra lösenordet krypterat men ändå kontrollera om användaren skriver in samma lösenord.

Jag hashar också passwords i databasen. Det enda som känns osäkert är om hashmetoden i sig skulle förändras om man måste flytta systemet till en ny plattform eller dylikt (updaterar något cryteringsobjekt eller annat som förändrar den kod som påverkar hashimplementeringen). Även fast text MD5 är standard så finns det väldigt många olika implementeringar i hur man gör en korrekt MD5. Det går att kolla upp om ens egna hashrutiner producerar en korrekt chechsumma via någon website (som jag ej kommer ihåg url till) och där kan man dubbelkolla sina hashade resultat innan man börjar släppa på users i databasen.

Så varför ska man använda DES-kryptering när man kan använda enkla md5 istället? Jag ser inga fördelar i ett så här enkelt exempel. MD5 är väl kraftigare med sina 128 bitar?

En mer flexibelt metod är att använda databasservens motsvarande krypteringsmetod. Från och med MySQL 4.1 är den på 160 bitar. Motsvarande funktion i äldre MySQL är inte alls lika säker och går förmodligen på kort tid att knäcka med brute force.

Ni måste göra skillnad på "kryptering" och "hashning" även om "hashning" även kallas envägskryptering.

Brute Force behöver vi inte överväga som knäckningsmetod då den slår lika hårt (eller snarare löst) mot båda metoderna.

Kryptering är däremot precis lika oseriöst som klartext i detta fall eftersom den som verkligen vill ha lösenorden sannolikt kan komma över era nyklar också (eftersom ni har nycklarna i era script för att kryptera/dekryptera) lösenordet.

Det är en korrekt iaktagelse att längden på nyckeln påverkar hur svårt det är att knäcka, men det är inte samma sak som att MD5 spottar ur sig 128 bitar. För längden på en MD5 hash talar bara om hur långt resultatet blir. Ett alternativ till MD5 är SHA1 som ger en hash på 160 bitar.

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

Så avslutningsvis påstår jag att om man lagrar lösenord som inte är hashade (och då helst SHA1 eller möjligen MD5) så är man inte seriös. I en perfekt värld så hashar man dessutom på klienten och inte på servern. men det är inte nödvändigt om man kör https.

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

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.

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.

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

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

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.

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.

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.

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

Faktiskt, i teorin (ja, i praktiken också) så finns det ett oändligt antal textsträngar som producerar ett identiskt hash, MEN det är omöjligt att i praktiken ens hitta 2st likadana.

Sen måste man givetvis sätta sitt eget systems "viktighet" i förhållande till den som ska hacka det... Jag tror inte att nationella säkerhetsorgan (med resurser och teknik) vill hacka era cmsverktyg eller ta över någon användares konto på eran site.
I en realistisk värld så kommer Nisse att testa några lösenord, kanske brutforce submitta lite innan han ger upp. :rolleyes:

I höstas var det en forskare som publicerade en artikel och hävdade att han hade lyckats ta en text hasha den och sedan manipulerat texten och lyckats få ut samma hash. Okej, möjligheten finns.

Men hur ska ett lösenord på kanske 8-10 tecken manipuleras? Troligen kommer antal möjliga kombinationer på 8-10 tecken aldrig att ge samma hash. För att få samma hash talar vi om textmassor. Möjligen dokument som innehåller tusentals tecken.

Låter intressant. Du vet inte var man kan hitta den artikeln?

*Hugger ett inlägg från högen*

Först av allt, som flera redan nämnt är det bra att skapa krypterade lösenord. Först för att man vet att flera använder samma lösenord till allt möjligt och sen även för att minimera skadan ifall någon skulle komma åt databasen.

Massa folk pratar om "bra salt". Vad är salt för något? 2 stycken slumpmässiga ASCII-tecken. Iallafall ifall man pratar om salt till crypt()-funktionen. (PHP använder ju unix-standardlibbet för det).

Om du i php kör crypt("foobar") så klämmer den dit 2 stycken tecken som salt. Vilka? Ja de får man reda på genom att titta på det krypterade lösenordet. Är krypterade lösenordet "RS4CNv1lS3cLo" så har saltet varit "RS". Salt är ju inte på något sätt hemligt. Snarare tvärtom. Det är allmänt känt.

Därför är det viktigt att när man ska KRYPTERA lösenordet så ska man inte använda samma lösenord som salt. Betrakta liten visning i python:

>>> from crypt import crypt
>>> crypt("foobar","RS")
'RS4CNv1lS3cLo'
>>> crypt("foobar","foobar")
'foa3VCPbMb8XQ'
>>>

(Cryptmodulen i python använder samma libbar som crypt() i php)

Som vi kan se.. så är första lösenordet "foobar" krypterat med salt RS. Vi fick RS4CNv1lS3cLo. Andra lösenordet är krypterat med "foobar" som salt, eller rättare sagt "fo". Som vi kan se börjar den andra krypterade strängen med "fo" i så fall och kan avslöja hur vårt lösenord börjar. (Ja förutsatt man har tillgång till koden och kan se denna miss).

Så i och med att crypt krypterar alltid likadant ifall man använder samma salt är ju det sättet det enda vi kan verifera lösenord.

Med andra ord... crypt("foobar", $cryptedpwd) använder första två tecken från $cryptedpwd som salt till att kryptera foobar. Är "foobar" rätt lösenord så ska resultatet bli samma som $cryptedpwd.

Med andra ord. "Bra salt" som någon skrev är allt förrutom de första två bokstäverna på lösenordet. :)

Det finns INGET sätt att dekryptera lösenordet. PUNKT. Det finns sätt att gissa dåliga lösenord (brute force), och det är inget som kan hindra en från att göra det mer än att ha databasen skyddad och kanske tillåta max 3 felaktiga loginförsök på en timma.

Om det är någon som känner eller tror att jag har fel där kan denne gärna försöka dekryptera:
BassB1YipTunI

Så personligen tycker jag inte något finns att säga emot crypt() när det kommer till UNIX. På Windows vet jag ärligt talat inte, men jag bryr mig inte heller. Den tar jag inte ens i med tång för att inte tala om att försöka implementera ens låtsassäkerhet.

/Zoran

Hmmm, jag brukar "salta" innan jag md5'ar...är det inte så man gör? I mitt fall är alltså saltet inbakad i den kompilerade .Net koden, vilket gör det svårare för någon med tillgång till servern att kolla upp saltvärdet/värdena (koden är dessutom obfuskerad). Förstod inte riktigt meningen med att se saltet ibörjan av av hashen?

Exempelvis:

"13MySAaAl98T" + strPassword + "11abc34SecondSaltTjolahopp998822"

.. detta hashas sedan.

Den paranoida kan ju alltid trippelhasha hashen så blir det svårare att endast leta efter ett salt i den dekompilerade koden utan man måste även in och titta i logiken.

Hehe, kul att du talar så varmt om unix crypt och att denna funktion fungerar utmärkt som substitut till hash-metoder.
Och jag kan bara hålla med för det unix crypt gör är just en hashning. Det är en envägsfunktion precis som MD5 och SHA1. Så det fungerar alldeles utmärkt.

Funktionens namn förvirrar, men som jag sa från början. Man måste göra skillnad på kryptering där man kan dekryptera (dvs utifrån kryptot återskapa klartexten) och hashning (kallas även envägskryptering) där man bara kan jämföra de "krypterade" strängarna och se om de matchar.

Robert: Ja ditt sätt att "salta" MD5-hashen adderar en dimension som försvårar försöken att återskapa algoritmen, men i praktiken saknar det betydelse eftersom saltet är konstant är det lika svårt att knäcka ett lösenord med salt som utan.

Meningen med ditt salt är alltså att ett och samma lösenord ska kunna få olika hashvärden.
Om t.ex. två användare har samma lösenord, t.ex. "apa", så kan det ena hashas till "hu832879wr98" och det andra till "ijogst8wisosy".

Detta är alltså bra så blir det jobbigare för någon som försöker brute-force:a en lista med lösenord.
Tänk dig att du har en ordbok med N ord (lösenord som du vill testa),
för att testa denna lista på en lösenordsfil med M användare som alla har olika salt så
måste du totalt hasha M*N lösenord (istället för N st).

Ex, vill du testa lösenordet "apa" på denna lista:
kalle:hu832879wr98
kajsa:ijogst8wisosy

Så får du först anropa crypt("apa","hu") och sedan crypt("apa","ij"), totalt 2 anrop alltså.

Hade listan haft samma salt, alltså:
kalle:hu832879wr98
kajsa:huogst8wisosy

Så hade det räckt att anropa crypt("apa","hu") 1 gång.

Du gör det helt enkelt livet lite jobbigare för den som vill brute-force:a. :)

Kan kort och gott citera min lärare i datasäkerhet.

"Allting är säkert tills den dagen någon jäkel ger sig fan på att lyckas"

Vill någon hacka er så gör personen det (det vill nu säga om personen innehar kunskapen).

Enda sättet att skapa säkerhet är om man kan tänka som hackaren och är RIKTIGT paranoid.

Har sett skräck exempel på säkerhet.

Ett community (namnet utelämnar jag) körde en SQL fråga i GET (?sql=select+*+from+table)
I själva koden låg det en <?=print_r()?> eller motsvarande bortkommenterad i html (<!-- -->)

Rätt tragiskt att det gick att köra tex. select * from users och sedan se resultaten i sidan...

Alla koder eller krypteringar går att dekryptera. Ta t.ex. RSA där krypteringen är öppen, dvs. den matematiska funktionen är känd. Att dekryptera en krypterad kod i RSA görs genom att prova alla kombinationer av de två nycklar som används för krypteringen. Det är bara det att för två nycklar med 4096 bitars längd tar det kanske 150 år för alla världens datorer att fixa det.

Att dölja en text behöver nödvändigtvis inte betyda att den aldrig ska gå att läsa, utan målet kan vara att dölja den tillräckligt länge. När texten väl är dekrypterad har den inget värde längre.

MD5 i osaltat format är inte speciellt säkert då de flesta användare har lösenord i form av namn eller ord som finns i språket.

En snabb sökning i en ej nämnd databas skulle lätt hitta ett lösenord av tio av lunarstorms användare och förmodligen fler då de flesta har tämligen "enkla" lösenord där och på många andra ställen där vanligt folk väljer sina egna lösenord som de sedan ska försöka komma ihåg.

Använd ett bra salt som tidigare talare påpekat om ni använder md5.

Du kritiserar fel sak tycker jag.
MD5 är precis lika säkert med som utan salt. Ett salt kan däremot skydda användare som väljer dåliga lösenord, men det påverkar på inget sätt styrkan i MD5. Och om saltet blir känt är det fortfarande användarnas dåliga (dvs lätta att gissa) lösenord som är den svagaste länken.

Det är kul att läsa att det tar xxxx antal år att knäcka koden yyyy, men varför berättar inte all statistiker att Murphys lag inte alltid gäller, dvs vem har sagt att det är det absolut sista försöket du lyckas knäcka med?

Om det sägs att det tar 15år att kolla igenom alla kombinationer så borde det, statistiskt, i snitt ligga på halva den tiden, dsv 50% av tiden. Det är faktiskt precis lika stor sannolikhet att man knäcker ett lösenord på första "försöket" som på det absolut sista "försöket". Men det var ju lite ot! =)

Det är sant, men det är ändå i praktiken omöjligt att knäcka koden inom en rimlig tid. Om det tar 7,5 år för all världens samlade datorkraftr att knäcka koden, hur lång tid tar det då för en grupp illasinnade krackers att hitta salt A och salt B med deras x antal datorer till sitt förfogande Nog om det.

Det hela blir en smula löjligt när diskussionen handlar om utifall t.ex. md5 är bra eller inte. Om utgångspunkten är att alla koder går att knäcka, så behövs det med andra ord ingen kryptering. Kryptering är inte ett ultimat sätt att döja något utan bara ett sätt att dölja något under en begränsad tid. Det handlar således om hur länge man vill att sin infomation inte ska vara tillgänglig.

I ett militärt sammanhang kan tid för att dölja något handla om minuter till månader. Det kan gälla en order som ska verkställas omedelbart eller om några dagar. Det är den tiden man vill dölja den för fienden.

Om jag då sätter det i relation till en medlemshemsida, så är döljandet först och främst till för att dölja det för andra som jobbar med medlemssidan och som inte ska ha tillgång till koderna. I nästa steg kan döljandet vara avsett för olyckor, dvs. något går fel och någon utomstående får tillgång till registret. Denna utomstånde kan vara vem som helst och sannolikheten att den då ska sätta igång med en avancerad dekryptering är försumbar.

I nästa steg kan det kanske vara aktuellt att dölja koden för någon illasinnad person. Låt säga att jag vill komma åt alla inloggningsuppgifter för medlemmar på Lunarstorm. Verkligen intressant, eller hur. Då kan jag logga in i andras namn och skriva elaka saker och så får någon annan skulden. Säkert går det att göra mer elaka saker än det. Frågan är bara, om den person som sitter på de resurseran och kunskaperna har något intresse av att komma åt dessa inloggningsuppgifter.

Som jag ser det, så är nog största risken för att mitt lösenord ska missbrukas inte genom en attack utifrån mot ett register utan från dem som arbetar med registret.

När Anna Lindh låg på sjukhuset, vilka var det då som missbrukade registren? Ja, inte var det attacker utifrån utan från insidan.

Således skulle någon som arbetar med ett register kunna på skoj prova en medlems användarnamn och lösenord på en annan medlemssida och kanske ha tur att bli inloggad. Från det skojet skulle det kunna leda vidare till mer illasinnade saker. Kanske sälja uppgifter till någon med ont uppsåt.

Låt säga att Spray har alla lösenord i klartext. En peson som har tillgång till dem hamnar i spelmissbruk och finner att det går att tjäna pengar på att sälja användaruppgifterna. Om dessa uppgifter vore krypterade är nog sannolikheten att de skulle säljas lika med noll.

Meningen att kunna se saltet är ju att du inte kan verifiera lösenordet utan ditt salt. Om du hashar ditt lösenord får du en obegriplig sträng. På något sätt måste du kunna få samma obegripliga sträng för att kunna verifiera och godkänna din användare. Antigen använder du "samma" salt till alla användare och då måste du hålla det hemligt. Annars är det onödigt.

Eller så lagrar du saltet för användaren en en separat tabell/databas.

Eller så som crypt gör, lagrar du saltet i det krypterade strängen som två första bokstäver.

Hur du en vrider och vänder på det hela, hjälper inte saltet mycket att få ett bra lösenord.

För att: Användarna ska inte komma åt sina krypterade lösenord (iallafall inte på reguljärbasis). Gör dem det så kan man anta att de kan på samma sätt komma åt saltet också.

Därför är det tämligen meningslöst att hålla saltet hemligare än självaste krypterade lösenordet.

/Zoran

Om jag inte har helt fel nu, så innebär det att ha ett lösenord som är krypterat med md5 utan salt att det bara är att sätta igång att prova sig fram med olika lösenord tills man hittar det rätta.

Om ett salt är används så kommer inte det att fungera eftersom jag måste känna till saltet för att kunna prova mig fram.

Guran gör ett par helt korrekta iaktagelser.
MD5 har ju i denna diskussion enbart varit ett exempel på hashning.
Och eftersom sannolikheten är störst att ett missbruk sker av den som enkalt har tillgång till DB och övriga script på sajten måste den rimliga slutsatsen bli:

1) Klartext är dumt.
2) Kryptering som kan dekrypteras (dvs inte hashning) är också dumt då nycklarna måste finnas tillgängliga på inloggningsservern och den som komemr åt DBn kommer sannolikt även åt nyklarna och kan då dekryptera alla lösenord.
3) Hashning är bästa alternativet eftersom ingen (utom att på mer eller mindre finurliga sätt gissa lösenorden) på ett annat sätt än att prova alla möjliga kombinationer kan komma fram till vad lösenorden är.

Dessa tre slutsatser är precis vad jag menade ursprungligen även om vägen hit varit lång och intressant. och med vissa omvägar...

Edit:
Nu han ju Guran göra ett inlägg till...
Det kommer visst fungera eftersom jag kommer testa all möjliga kombinationer utan att ta hänsyn till saltet. När jag knäckt två hashkoder med samma salt kommer jag kunna utläsa saltet själv.
Exempel:
nisse hashas med saltet gurra. Även ola hashas med saltet gurra. När jag testat mig fram med alla möjliga kombinationer så kommer jag ha "nissegurra" och "olagurra" och kan då dra slutsatsen att båda hashats med saltet "gurra".
Saltet gör det alltså inte svårare att med brute force "knäcka" koden. Däremot gör saltet det svårare att gissa lösenord (eller leta med en stor i förväg uträknad tabell med hashkoder). Detta gäller ju självklart bara om saltet är okänt och enligt tidigare; om en person kan komma över ev. kryponyklar kan han komma över saltet...
Detta betyder inte att man inte skall använda salt eftersom vi ju även kommit fram till att användare med dåliga (=lätt gissade) lösenord skyddas lite extra (med betoning på lite för är lösenorden lättgissade så kan jag ju testa utan att ens veta hashen).

Mjao, det hela beror väl på hur den hackingrutin som testar ahshen fungerar.
Kör den "totalslump" så kan man komma långt med att ha en mycket lång salt, för någonstans i gissningsarbetet i hackingrutinen så måste det göras en avgränsning, exempelvis att den går från 4 tecken upp till 20. Att ha en hash bidrar givetvis till mer säkerhet ur dictionary based hacking-synpunkt då den förvanskar tama passwords typ "johanna" eller "abc123" till något icke mänskligt.
Att sedan gömma en hashningsmetod i logiken, alltså att man kanske dubbelhashar med extra salt etc kräver aningen mer av en som gör intrång i koden.

Nu anser jag att har någon obehörig tillgång till din kälkod så är ändå skadan skedd. Jag har iaf, då jag kör asp.net, endast den kompilerade och obfuskerade koden på produktionsservern så även om du sitter på servern och glor så måste du ha ganska så mycket kunskap för att glo i dessa filer.

Alltså som många redan påpekat; saltet gör inte MD5 hashningen säkrare som algorithm men ger mer säkerhet än att köra utan.

Allt som går att göra åt det ena hållet - går att göra åt det andra.
Precis som en ekvation så kan man räkna ut den baklänges.
"Alla" tror att det är omöjligt att knäcka men det går. Man kanske inte får ut samma lösenord som användaren hade, men man kan komma fram till ett som har samma hash/encrypt som det riktiga lösenordet. Och då kan man ju komma in iallafall.
Det seriösaste är väll att se till så att ens användare använder lösenord som är långa och inte används på något annat ställe. Hash/encrypt är väll bättre än ingenting men det viktigaste är väll att ingen kommer åt datan. Har man databasen på ett hotel så ska man nog hasha/encrypta ifall någon kollar. Det är väll knappast oseriöst ifall admin kollar vilket lösenord någon har, snarare idiotiskt. Man brukar väll koda så att admin har rättigheter att ändra allt iallafall?
Något som är oseriöst är användare som har sitt namn som lösen och liknande. Då får dom skylla sig själva. Om man inte hashar/encryptar så kan man lätt se vilka användare som har lätta lösen och meddela dom att dom borde byta. Annars kan man ha fler regler när någon väljer lösen, typ: Minst 10 tecken, Minst 3 olika tecken typer (av 4: A,a,1,!), kan inte innehålla ord som finns i ett lexicon. (kul att lägga in alla ord ;) )
Det är bara det att då får man kanske inte så många medlemar =P
Så tänk på detta: Lösenorden ska vara lika svåra som innehållet man får tillgång till är viktigt. Och låt inte någon få tag i informationen i db:n för då kommer dom in iallafall!

Det som är speciellt med RSA som används i t.ex. PGP är att det är en ekvation som inte går att räkna ut baklänges. Den använder sig av två nycklar A och B för krypteringen. Enda sättet att dekryptera den är att känna till A och B. Vill någon utomstånde dekryptera meddelandet så är det bara att testa sig fram till vad A och B kan vara.

Det låter väl inte så svårt. Går väl snabbt att prova sig fram med en eller några datorer? Med två nycklar på 4096 bits, så kan man låta alla datorer på jorden jobba på det och ingen av oss som läser i detta forum i dagsläget skulle vara i livet när meddelandet väl är dekrypterat.

För att vara lite ironisk. Jag tror nog att det skulle duga till en medlemsajt.

Duger gör det helt klart utan problem, jag ville bara påpeka att ingenting är 100% säkert. En liten MD5 kan man köra ;) men glömm inte att se till att användarna har ordentliga passwords. Rätt trist om man gör en massa för att ingen ska kunna få ut lösenorden och så är lisas password lisa så man kan gissa det iallafall =P