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.