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