Om du hashat lösenordet med md5 så går det inte att reversa. Det man kan göra är att testa olika kombinationer (t.ex. ord från en databas) och hasha dem för att sedan jämföra med det hashade lösenordet. Om hemsidan skippade saltet och du hittade en kombination som ger samma hash så skulle du kunna logga in, men inte om saltet finns med (jag förutsätter att saltet är okänt för hackaren) Observera dock att md5 inte är en injektiv funktion så bara för att md5(x) = md5($pswd) så har du inte att x = $pswd. Om du då använder x på en annan hemsida som inte använder md5 (eller samma salt) lär du inte komma in.

Still - vi säger att "Kalle" och "Petter" har samma lösenord, de får då även samma hash.
Vi säger också att en eventuell hackare kommer över databasen, och kommer över lösenordet för en hash - då kan han söka efter den hashen mot övriga användarnamn, och därmed veta att han har samma lösenord.
Mitt tips är, som jag tidigare hämde, att även slänga in ett dynamiskt värde som är unikt till användaren, vilket lämpligast är användarnamnet.

aah, har inte tänkt så.

Är det ingen sajt som drar in några vettiga pengar (i förhållande till arbetsinsats givetvis) och man inte har speciellt mycket tid och allt har fungerat fint fram tills dags dato så gör man inte något. Det handlar sällan om okunskap vilket alla flitigt påpekar gång gå gång.... De här diskussionerna börjar bli tjatiga och rejält långtråkiga....

Instämmer dock här då tror jag att det handlar om okunskap.
I början så gjorde man ju precis samma sak, dvs, körde allt i klartext.
Sedan lärde man ju sig md5(), och strax efter det så fick man reda på att det var ganska värdelöst vid diverse rainbow-tables, och då flyttade över till salt.
Genom då att tänka vidare lite så började jag pleta in deras användarnamn så att alla hashar är unika.

Dock så instämmer jag att tråden börjar bli tjatig och bör härmed låsas om ingen har något vettigt att säga om själva intrånget. ;)

Mja, att påstå att MD5 är ganska värdelöst är väl mer än en rejäl överdrift...?

Om man samtidigt har en policy som till exempel tvingar användaren att skapa lösenord med både gemena och versala bokstäver och en eller flera siffror och tvingar minst 8 tecken skulle jag gissa att du inte hittar mer än ett par av dessa lösenord i någon regnbågstabell i världen...

Men visst, med dessa tabeller kan man kanske få fram ett lösenord, men bara om användarna skapar väldigt simpla lösenord.

Möjligen, men jag gillar inte heller att "tvinga" användaren att använda ett annat lösenord än vad personen i fråga själv vill använda.
Då ser jag heller som jag påpekat massa gånger tidigare, en rejäl salt, och där användaren får ha precis vilket lösenord hon/han vill.

Vidare, om då användaren väljer att ha lösenordet "a", så är det sårbart mot dictionary/bruteforce attack (vilket man kan skydda sig via serverside).

Kommer angriparen åt källkoden så kan denne generera saltet själv eftersom han vet hur det är uppbyggt. Han väljer ut en administratör, skriver ihop ett bruteforce-skript som inkluderar saltet...
För att få det så säkert som möjligt ska man alltså hasha lösenord + unikt salt för varje användare, samt kräva ett starkt lösenord.

hur skulle en sådan kod se ut?


skulle vara schysst, bara att man ändrar på salten sen ju :)

och variabel för användarnamn?

man ska verkligen inte tvinga "EXTRA SÄKERT" lösenord!
det leder till att folk sparar dom på papper, browsers, i handflatan, glömmer av dom osv osv.
och det skapar stor irritation att man ska behöva kunna 30 olika lösenord till olika siter för alla har olika krav osv osv..
Själv är jag tvungen att kunna många olika svårknäckta lösen i huvudet men det är av egen fri vilja till mina egna saker.
Till andra siter drar jag mig för att använda 16+ tecken med minst 3 stora och minst 3 små tecken, minst 3 "special" tecken och sen en magisk symbol som ingen hittar..
Ork.
Salta+kryptering på säkert vis på serverside istället.